[BUG] Desktop app re-sends initialize + get_workspace_diff to an on-screen Remote Control session every 60 s; the system/init+status flood pushes the conversation past the 2,000-event window the transcript loader reads, so the session opens as "No messages yet"

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

Two behaviors combine so that a long-lived Remote Control session opens as **"No messages yet"** in claude.ai/code and in the Claude desktop app, even though the conversation is intact on disk *and* on the server.

**1. The desktop app re-sends `initialize` (and `get_workspace_diff`) to a Remote Control session every 60 seconds while that session is on screen.**

Every minute the CLI receives a burst of `control_request` `subtype=initialize` (2–3 of them; one request_id is delivered twice) followed by one `get_workspace_diff`. The CLI answers each `initialize` with a `control_response` **and emits a fresh `system/init` and `system/status` event** into the session's server-side event log. That is ~14 events per minute, ~800+ events per hour, per session that is merely being looked at. Nothing is typed; no turn runs.

The polling is tied to the session being visible: it starts the moment the desktop app shows the session and stops as soon as another session is selected. If several remote sessions are visible at once (split panes / pop-outs), all of them are polled. In our logs 8 sessions were polled in lockstep (identical start/stop minutes) for hours — one of them for ~12 hours, until the CLI retired it — because an operator left them open overnight.

A plain browser tab (Chrome 151, claude.ai/code) does **not** do this: foreground, background (8 min), with the diff panel open, and even after sending a message from the web (that sends `initialize` x2 + `mcp_set_servers` once) we observed zero periodic requests. Only the desktop app polls.

**2. The transcript loader only looks at the newest 2,000 events and gives up.**

When a session is opened, the web bundle (same in the desktop app) fetches
`GET /v1/code/sessions//events?limit=500&sort_order=desc` and follows `cursor` for **four pages (2,000 events)**, then stops and renders only the `user`/`assistant` events it found. If the newest 2,000 events are all `control_request`/`control_response`/`system init`/`system status` noise from (1), the view shows **"No messages yet"** plus a **"Load earlier messages"** button; each click loads 500 more. For one of our sessions the conversation only appears after 8 clicks.

So any session that was left on screen in the desktop app for more than ~2.5 hours and then had no further turns looks empty the next time it is opened. Sessions that got a new turn afterwards look fine (the new turn is at the top; the old history is just hidden behind the button), which is why this looks intermittent.

**Numbers from one affected session** (`cse_01VZ9M4nD9nAdUKZRqesT4TY`, Opus 5, started with `claude --bg --remote-control`, CLI 2.1.272):

- 9,081 events on the server, of which 205 are `user`/`assistant`. The last conversation event is `sequence_num` 3654.
- 5,427 events after the last conversation event: 2,501 `control_request` (1,869 `initialize`, 627 `get_workspace_diff`, 3 `mcp_set_servers`, 2 `get_context_usage`), 2,501 `control_response`, 1,939 `system/init`, 1,875 `system/status`.
- `initialize` cadence: bursts of 3 exactly 60 s apart (gap histogram: 1,234 x 0 s, 501 x 60 s), in runs of up to 4.4 hours. `get_workspace_diff` gaps: 513 x 60 s.
- 5 more sessions from the same day have 2,700–5,400 noise events after their last message and all open as "No messages yet".

**Regression timeline** (same account, same workflow — sessions were always left open in the app):

| Desktop app | `initialize` per hour on a session left on screen |
|---|---|
| 1.44121.4 (until 2026-09-04) | <= 20 (only when a human actually interacted) |
| 1.46388.1 (installed 2026-09-04 14:03 KST) | 120 (2 per minute) from 2026-09-05 |
| 1.52386.6 (installed 2026-09-14) | 180 (3 per minute) from 2026-09-14 |

Before 2026-09-04, sessions left open all day never accumulated more than a few dozen `initialize` events, so the 2,000-event loader window was never a problem.

### What Should Happen?

- The desktop app should not re-`initialize` a session on a timer (or, if it needs to refresh permission mode / model / commands, that refresh should not make the CLI append `system/init` + `system/status` events to the session's persistent event log every time).
- The transcript loader should not declare "No messages yet" while older pages exist. It should keep paging until it finds conversation events (or the server could expose the cursor of the last `user`/`assistant` event so the client can jump there), and control/system chatter should not count toward the window.

### Error Messages/Logs

```shell
# CLI side (--debug-file) while the desktop app shows the session — repeats every 60 s, nothing typed:
2026-09-14T09:10:38.214Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:10:38.261Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:10:38.496Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:10:38.819Z [DEBUG] [bridge:repl] Inbound control_request subtype=get_workspace_diff
2026-09-14T09:11:38.262Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:11:38.322Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:11:38.550Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:11:38.820Z [DEBUG] [bridge:repl] Inbound control_request subtype=get_workspace_diff
2026-09-14T09:12:38.192Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:12:38.229Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:12:38.447Z [DEBUG] [bridge:repl] Inbound control_request subtype=initialize
2026-09-14T09:12:38.778Z [DEBUG] [bridge:repl] Inbound control_request subtype=get_workspace_diff
# (no "resuming stream deltas" / reconnect lines in between — the subscription stays up; this is a timer, not a reconnect loop)

# Server event log for the same session, newest first (GET /v1/code/sessions//events?limit=500&sort_order=desc):
# 5,427 consecutive events of these types sit above the first user/assistant event:
# control_request(initialize) -> control_response -> system(init) -> system(status) x 1,869
# control_request(get_workspace_diff) -> control_response x 627

# What the web bundle requests when the session is opened (browser network log), then it stops:
GET https://claude.ai/v1/code/sessions/session_01VZ9M4nD9nAdUKZRqesT4TY/events?limit=500&sort_order=desc
GET https://claude.ai/v1/code/sessions/session_01VZ9M4nD9nAdUKZRqesT4TY/events?limit=500&sort_order=desc&cursor=8883
GET https://claude.ai/v1/code/sessions/session_01VZ9M4nD9nAdUKZRqesT4TY/events?limit=500&sort_order=desc&cursor=8383
GET https://claude.ai/v1/code/sessions/session_01VZ9M4nD9nAdUKZRqesT4TY/events?limit=500&sort_order=desc&cursor=7883
# UI: "No messages yet" + "Load earlier messages" (Korean UI: "아직 메시지가 없습니다" / "이전 메시지 불러오기").
# Each click on the button issues one more page (cursor=7383, ...); the conversation appears after the 8th click.
```

### Steps to Reproduce

1. Start a background Remote Control session with a debug log, e.g. `claude --bg --remote-control --name test --debug-file %TEMP%\test.log "Reply with exactly the word: ok"` (CLI 2.1.272).
2. Open that session in the Claude desktop app (Windows, 1.52386.6) and simply leave it on screen. Watch the debug log: every 60 s you get 2–3 `Inbound control_request subtype=initialize` plus one `get_workspace_diff`, and `GET /v1/code/sessions//events` on the server shows a new `system`/`init` + `system`/`status` pair per `initialize`. Select a different session in the sidebar: the polling stops immediately. (Open the same URL in a plain browser instead: nothing is polled.)
3. Leave the session on screen for ~2.5 hours without sending anything (or open several sessions in split panes to get there faster), so that more than 2,000 events accumulate after the last `user`/`assistant` event.
4. Close it, then open the session again from claude.ai/code or the desktop app: the view says "No messages yet" with a "Load earlier messages" button, although the transcript on disk and the server event log both contain the full conversation. Clicking "Load earlier messages" ceil((noise - 2000) / 500) times brings the conversation back.

### Claude Model

Opus

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

Desktop app 1.44121.4 (before the 2026-09-04 update to 1.46388.1); the polling is present in 1.46388.1 and 1.52386.6. The CLI side only answers the requests; the timer is in the app.

### Claude Code Version

2.1.272 (Claude Code) — standalone CLI hosting the `--bg --remote-control` sessions; desktop app 1.52386.6 bundles 2.1.270

### Platform

Anthropic API (claude.ai account, OAuth)

### Operating System

Windows (11 Pro 26200) for both the CLI host and the desktop app

### Additional Context

- The affected sessions are long-lived `--bg --remote-control` sessions that a small team opens via `https://claude.ai/code/session_…` links from an internal tool, so they are opened and re-opened over days; that is why the missing history is noticed. Nothing in our tooling talks to the session's control channel — the only clients are the desktop app, claude.ai/code in a browser, and the Android app.
- Archiving/re-creating the bridge is not a workaround for us: a fresh bridge has no server-side history at all.