Session list dot ignores the server's post-turn state for Remote Control sessions — neither "needs input" nor "unread" ever appears

Status Open
Reported on v2.1.261
Maintainer reply None cached
Activity 0 comments · opened Sep 4, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

In the web client (claude.ai/code, and the desktop app that embeds it), the session
list dot for a Remote Control session only ever reflects live state: it blinks while
the turn is running, and it turns amber while an AskUserQuestion card is pending.
Everything the server says about how the turn ENDED is ignored.

The server does supply that information. GET /v1/code/sessions returns, per session:

  • unread: true
  • status_bucket: "review_ready" for a turn that finished cleanly, or "blocked" for one

that finished needing something from me

  • post_turn_summary.status_category, which can be need_input

The mobile app renders this. The web client does not. For the same session, at the
same moment, on the same account:

| Session ended | Server says | Mobile | Web client |
|-----------------------------|----------------------------------|--------|--------------|
| cleanly, unread | review_ready, unread: true | blue | hollow ring |
| with a question in prose | blocked / need_input, unread | blue | hollow ring |
| with an AskUserQuestion card| pending approval | blue | amber — works|

So the only case that works is the one driven by live state. As soon as the turn is
over, the dot goes blank regardless of what the server reports.

Note that the mobile app does not appear to have a "needs input" state at all: it shows
the same blue unread dot in all three cases, including the pending AskUserQuestion card
that the web client renders amber. So mobile is not a reference implementation for the
amber half — the ask here is that the web client use the post-turn state the server
already sends, not that it copy mobile.

The dot does render blue and amber correctly if I mark a session unread by hand, so
this is not a rendering problem — the automatic path never reads the server state.

Why this is one bug and not two: both missing states are post-turn state, and both are
present in the same API response the client already has in hand. The intended
semantics look clear from the field names — amber when Claude is waiting for me, blue
when the turn is over and there is something unread. Neither fires.

What Should Happen?

Amber when the server reports the turn ended needing input (status_bucket "blocked" or
post_turn_summary.status_category "need_input"), and blue when it ended cleanly and is
still unread — the same way the mobile app already does it from the same data.

Error Messages/Logs

Steps to Reproduce

  1. Run claude rc on a machine to make it a Remote Control host.
  2. From the desktop app or claude.ai/code, start a session on that host.
  3. Let it finish a turn — either cleanly, or ending with a question in prose. Do NOT

use an AskUserQuestion card; that case works.

  1. Do NOT open the session. Wait past the 30s session-list refresh.
  2. Compare the session list in the web client with the same list in the mobile app.

Expected: blue for the clean finish, amber for the one that needs input.
Actual: a hollow ring in both cases. The mobile app marks both unread.

Reproduced across four clients, same account, same sessions, minutes apart:

| Client | Post-turn state shown? |
|-------------------------------|---------------------------------|
| Mobile app (iOS) | Yes — blue, clears on open |
| Firefox, Linux | No |
| Desktop app, Linux | No |
| Desktop app, Windows | No |
| Desktop app, LOCAL session | Yes — blue, plus a notification |

Still current. At the time of writing, GET /v1/code/sessions lists eight sessions with
worker_status "idle" and unread true — five of them status_bucket "blocked", three
"review_ready". Every one of them is a hollow ring in the desktop sidebar. A session in
the same list with unread false is also a hollow ring, so the two are indistinguishable.

Ruled out: latency (waited far past the refresh), OS and packaging (reproduces in an
unmodified Firefox and on Windows), session type (a local session in the same desktop
app shows the marker and fires an OS notification), how Remote Control is started
(same by hand and as a systemd user unit), and client-side read state (it happens on
sessions I have never opened, including in a browser profile that had never seen
them).

Neighbouring issues, none of them this one: #89778 (unread silently cleared on local
sessions via bad lastFocusedAt stamping — my local sessions behave correctly), #81568
(per-device read state; that reporter sees the marker on desktop, mine never appears —
the difference between our setups may be the clue), #90081 (isRunning latches on for
local sessions), #92114 (iOS gray vs green), #32628 (blue markers missing on macOS,
closed not planned), #56770 and #64193 (sticky amber, closed as duplicates), #72468
(dots hard to tell apart).

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.261 (Remote Control host). Desktop app 1.40609.1. First observed on 2.1.251 / 1.37937.3 and re-confirmed unchanged on the versions above.

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Note on the form: this bug is in the web client and the desktop app, not the CLI, so
the Terminal/Shell field does not really apply. The OS field says Other Linux
(Arch), but the same behaviour reproduces on the Windows desktop app and in an
unmodified Firefox on Linux, so neither the OS nor the packaging is a factor.

Session titles in the screenshots are blurred; the status dots are untouched.

<img width="393" height="801" alt="Image" src="https://github.com/user-attachments/assets/33dfdacc-af8e-484a-a1ea-94ebc311d81c" />

Web client: every session shows a hollow ring, none marked unread.
<img width="1170" height="2159" alt="Image" src="https://github.com/user-attachments/assets/b196e493-61a1-47eb-91d2-24fd2256d65d" />

Mobile app, same time, same sessions: blue unread dot present.

<img width="1170" height="2245" alt="Image" src="https://github.com/user-attachments/assets/704fe54f-e24b-4d88-978c-ad31d6ea7c4b" />

Mobile app a few minutes later: still marking these sessions unread.

<img width="422" height="788" alt="Image" src="https://github.com/user-attachments/assets/271a99e6-7561-4f9a-b0c3-1cb31a0f2938" />

→ *Web client after marking the sessions unread by hand — the marker does render,
so the renderer is fine; the automatic path is not.*

Disclosure: the reproduction is mine — I ran it by hand across four clients (iOS
app, Firefox on Linux, and the desktop app on both Linux and Windows), and every
screenshot comes from those runs. The search for existing reports and the drafting
of this issue were done with Claude Code.

Happy to run further tests or pull more detail from my setup if that helps.

View original on GitHub ↗