Ghostty right-click context menu degrades during long sessions, with CLAUDE_CODE_NO_FLICKER unset

Ghostty right-click context menu degrades during long sessions, with CLAUDE_CODE_NO_FLICKER unset

Summary

During a long Claude Code session in Ghostty, the terminal's native right-click context
menu stops appearing. Copy and paste remain reachable only through the macOS menu bar.
Quitting and relaunching Ghostty restores it immediately, and it then works again until
the session has run for a while.

This is the same end state as #42908, but that issue was closed as not planned on the
understanding that the trigger is CLAUDE_CODE_NO_FLICKER=1. That variable is not set
here, by any means. Either no-flicker rendering can now be reached by some path other
than the environment variable, or this is a second cause with the same symptom.

The onset is the part that differs from #42908 and that I have not seen reported: there
the breakage is immediate, here it appears only after the session has been running, which
is why a restart looks like a fix.

Environment

| | |
|---|---|
| Claude Code | 2.1.233 |
| Ghostty | 1.3.1 |
| macOS | 26.5.2 (25F84), arm64 |
| TERM | xterm-ghostty |
| TERM_PROGRAM | ghostty |
| Ghostty config | none present; stock defaults |
| claude binary | ~/.local/bin/claude, Mach-O 64-bit arm64 |

The variable is not set

Checked every source it could come from:

env | grep CLAUDE_CODE_NO_FLICKER        -> unset
~/.zshrc  ~/.zprofile  ~/.zshenv          -> no match
~/.claude/settings.json                   -> no "env" block at all
~/.local/bin/claude                       -> a Mach-O binary, not a shell wrapper
                                             that could export it
Ghostty process                           -> launched with no special environment
~/.config/ghostty/config                  -> does not exist

The only three files on disk containing the string CLAUDE_CODE_NO_FLICKER are the
Claude Code changelog, my shell history from grepping for it, and the session transcript
where I discussed it.

Steps to reproduce

1. Launch Ghostty (1.3.1, no config file) on macOS 26.5.2.
2. Right-click in the terminal. The native context menu appears normally: paste, split,

reset terminal.

1. Start claude and work in a single session that produces a lot of output. I did not

time the onset, so I cannot give a threshold: the session had been running for a while
with heavy tool output and large scrollback before I noticed. Somebody who can watch
for it deliberately would pin this down better than I can.

1. Right-click again. No context menu. Copy and paste are reachable only from the menu

bar.

1. Quit Ghostty entirely (Cmd-Q) and relaunch. The context menu works again.

Expected

The native Ghostty context menu keeps working for the life of the session, as it does
before Claude Code has been running for a while.

Actual

It stops appearing partway through a long session and does not come back until Ghostty is
restarted. Cmd-C and Cmd-V continue to work throughout, so only the context-menu path is
affected, which matches the event-swallowing description in #42908.

Hypothesis

If the alt-screen / virtualized-scrollback renderer described in the changelog entry for
CLAUDE_CODE_NO_FLICKER=1 can also be entered automatically once scrollback grows past
some size, that would explain all three observations at once: correct behavior early,
failure later, and a clean restart fixing it. I have not verified this and have no
visibility into which renderer is active.

If that is right, the fix for #42908 would need to cover the automatic path as well as the
explicit flag.

Questions

1. Can no-flicker or alt-screen rendering be activated by anything other than

CLAUDE_CODE_NO_FLICKER=1 in 2.1.233, for example a scrollback-size threshold or
terminal capability detection?

1. Is CLAUDE_CODE_NO_FLICKER=0 honored as an explicit opt-out, or is only the presence

of =1 checked? If the former, that is a usable workaround and worth documenting.

1. Is there a way to log or query which renderer a running session is using, so this can

be confirmed rather than inferred?

Related

• #42908, right-click context menu broken with CLAUDE_CODE_NO_FLICKER=1, closed as not

planned. Same symptom, documented trigger absent here.

• ghostty-org/ghostty discussion #12078, right-click release can be missed leaving mouse

state stuck. Different mechanism, since a restart of Ghostty alone fixes this and no
stuck drag state is observed.