Cursor Agent CLI — unreadable prompt inside GNU screen (OK without screen)

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When I run the Cursor Agent CLI inside GNU screen, the prompt / input area uses dark brown text on a black background and is hard to read.
The same CLI in Terminal.app without screen looks fine. Screenshot attached of my preferred environment.

Steps to Reproduce

  1. Open Terminal.app with the Novel profile.
  2. Start screen and open or attach to a session.
  3. cd to any project and run agent (interactive mode).
  4. Look at the bottom prompt / input strip (e.g. placeholder like “Add a follow-up”).
  5. Compare: quit screen or use a new tab without screen, run agent again — prompt text is readable.

Expected Behavior

Prompt and primary UI text stay readable whether the parent TTY is plain Terminal or screen.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

• Mac mini (Mac14,12), Apple M2 Pro, arm64
• macOS 26.4.1 (25E253)
• Terminal.app, profile Novel
• Cursor Agent CLI 2026.04.17-787b533
• Multiplexer: GNU screen (homebrew: Screen version 4.00.03 (FAU) 23-Oct-06)

For AI issues: which model did you use?

Not related; this is a CLI specific “accessibility issue” based on my choice of themes and eye-strain.

Additional Information

  • Screen is a builtin macOS standard for multiplexing and is common for old school *UNIX folks like myself for developer productivity.
  • Switching to tmux is not optimal for my productivity
  • I prefer builtin macOS tooling; I would potentially accept recommendations for “better” / “more compatible” options that provide a better cursor experience.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Workaround, cursor helped create:

bash-3.2$ alias agent
alias agent='/Users/hweingard/Projects/git.hrbx.me/dotfiles/.cursor/scripts/agent-launcher.sh'

Which rewrote color control characters returned from cursor-cli

Hey, thanks for the detailed report, and especially for the workaround, it’s really helpful.

This is part of a known class of bugs in the CLI. Theme detection via OSC 11 doesn’t handle GNU screen. There’s no timeout extension for STY, and there’s no DCS passthrough wrapping for the probe. Because of that, detection times out and falls back to a palette with poor contrast on your background. With tmux and SSH this is already worked around, but with screen it isn’t.

I’ve reported this internally as an additional repro case for the existing issue about prompt bar contrast. I can’t share a fix timeline yet. When there’s an update, I’ll reply in the thread.

For now, the alias wrapper workaround is a solid approach. If it helps anyone else, the script rewrites color control sequences from cursor-agent on the fly.