Left arrow never opens agent view in some sessions (persistent for the whole session, retrying doesn't help)

What happens

In some sessions, the left arrow key never opens the agent view. It does nothing at all — no agent view, no hint, no visible reaction, exactly as if the key had not been pressed.

The important part is that this is a property of the session, not of the individual keypress. Most sessions are fine and the arrow works every time. A minority are dead from the start, and in those, retrying does not help — pressing again, waiting, pressing slowly, clearing the input first, none of it makes any difference. The session is simply one where left arrow does nothing.

I have not found anything I do differently in the bad sessions. There is no error, no message, and nothing in the UI that distinguishes them from working ones as far as I can tell.

This has been happening for at least a week, probably longer. Currently on 2.1.259, but it predates that version.

What I expected

Left arrow on an empty prompt opens the agent view, in every session.

How often

A minority of sessions, but often enough to be a regular annoyance. I do not have a count.

Reproduction

I cannot reproduce it deliberately. I only notice it once a session is already in the bad state. Since it seems fixed for the lifetime of a session, it is presumably decided by something at session start rather than by what I do afterwards.

One guess, offered as a guess only: it may be more common in sessions that have subagents running. I have not verified this and it may well be coincidence.

Workaround

claude agents works and is unaffected.

A possible lead, with heavy caveats

I want to be clear this part is speculation and should not be taken as a diagnosis — treat the observations above as the actual report.

I poked at the 2.1.259 bundle out of curiosity. There is a gate that decides whether the left-arrow handler is installed at all, and it fails closed for a whole session on any of: fleet disabled, isRemote, persistence disabled, or isExternalLoading. Those are session-scoped, which is at least the right shape for a failure that is fixed for a session's lifetime and immune to retrying. I have no evidence that any of them is actually what fires in my bad sessions.

Separately there is a per-keypress state machine (a soloKeypress check that rejects an arrow if its stdin chunk carried more than one key event, and a 1 s window that silently absorbs a repeated press). I originally thought that was the explanation, but it predicts occasional misses that clear when you try again, which is not what I see — retrying never works. So I do not think that is my bug, though the silent-absorb behaviour may be worth a look on its own.

If it helps narrow things down: the footer hint reading ← for agents appears to be rendered from the same session-scoped gate as the handler. So if someone can confirm whether that hint is present or absent in a broken session, that should cheaply separate "gate closed for this session" from "gate open but the keypress is being dropped". I will check that the next time I catch one.