[BUG] Task list panel does not repaint on returning to a session; still present in 2.1.251 (re-report of #50656)

Version: 2.1.251 (GIT_SHA 37534ac, BUILD_TIME 2026-08-28T14:51:38Z) · Platform: darwin arm64 (Darwin 25.6.0)

Preflight

Searched existing issues. This is a re-report of #50656, closed NOT_PLANNED by the stale bot on 2026-05-26 and confirmed still reproducing on 2.1.173 (Windows Server 2022) in a 2026-07-21 comment that did not reopen it. The stale-close message invites a new issue if still relevant, so this is that.

• #88129 (open) describes the same mechanism from a feature angle — the panel never repaints from disk, only a mutating task-tool call repaints it.
• #86492 (open) is the same symptom with a different trigger (returning from the all-sessions view).
• #76493 (open) is a related but distinct agent-view fork that drops the store.
• Not #76844 — see Differential below. That one is an addressing bug; this is a repaint bug.

What is new since #50656: it still reproduces on 2.1.251 / macOS; agent-teams can be ruled out as the cause (differential below), which matters because #76844 makes teams the obvious suspect; and a secondary .highwatermark observation that appears in none of the above.

What happened

Returned to a long-lived session whose task store had gone 4 days 19 hours without a write. The task panel rendered empty. The store was intact throughout — 27 task JSON files, readable — and the periodic system-reminder was listing all 27 tasks to the model. The panel stayed empty for ~18 minutes, including a stretch of read-only shell inspection of the store, and was next reported visible after two TaskUpdate calls.

Timeline

T+0 is the first transcript record after the gap. Task-tool calls are exact; the user reports are their message timestamps.

| offset | event |
|---|---|
| T+0 | session used again — panel empty |
| T+6.9m | user reports the task list missing |
| T+6.9 … T+15.6m | investigation: shell reads of the store only (ls/cat/parse). No task-tool call of any kind. |
| T+15.6m | user reports it still not showing |
| T+17.8m | first task write in 4d19h — TaskUpdate (status) |
| T+23.9m | second write — TaskUpdate (description) |
| T+31.1m | user reports the panel is visible |

Exactly two task-tool calls occurred that day, both writes, at T+17.8m and T+23.9m. Verified by scanning the transcript for TaskCreate/TaskUpdate/TaskList/TaskGet.

What this does and does not show. It shows the panel was empty across an 18-minute window in which the store was intact and no task write occurred, and that it was next observed populated after two writes. It does not isolate the writes as the trigger — other tool calls and turn boundaries fell in the same interval, and the panel was next observed 7 minutes after the second write. And no task-tool read was ever attempted that day, so I cannot say whether a TaskList call would have repainted it; only that shell-level reads did not. #50656 and #88129 both report the write-trigger directly, which is why I read this as the same bug rather than a coincidence.

Repro

Return to a session after the task store has gone several days without a write, and make no task modifications.
Expected: the panel renders the existing list. Observed: empty until a task write.

Differential vs #76844

#76844 is an addressing bug: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 creates an implicit team whose name becomes the task-list id, so on resume the list points at a different store. That chain did not fire here:

| #76844 | here |
|---|---|
| task dir changes; original orphaned | same dir throughout, no sibling store |
| numbering restarts at #1 | ids continued; nothing below the pre-gap minimum |
| TaskList returns empty | store intact and readable; reminder listed all 27 |
| failure: data unreachable | failure: data reachable, panel not drawn |

The env var is set here, so an implicit team exists — created ~1 min before the first record of the day, with exactly one member (this session as its own team-lead, backendType: "in-process"). No teammate joined that I can observe, and task files carry no team or agent key: the observed field union is blockedBy, blocks, description, id, status, subject, plus activeForm on 10 of 27. I have not tested with the flag off — but the July confirmation on #50656 was Windows Server, and #50656 predates the teams flag entirely, so teams is not a precondition for this bug.

Session characteristics

Offered only in case a size or age threshold is relevant; #50656's reporters did not describe outlier sessions, so it probably is not.

• spans ~75 calendar days; 51 distinct active days (JST)
• a single distinct sessionId across every record that carries one
• never forked — unbroken parent chain, no sidechain records, no separate fork transcript
• but reopened many times: the transcript carries 31 distinct CLI version strings advancing 2.1.177 → 2.1.251, and 12 auto-compactions. A live process cannot restamp its own version, so the CLI was relaunched against this transcript at least 30 times.
• ~44k records, ~178 MB (~169 MiB), growing — figures are as-of-measurement, not fixed
• store: 27 task files, ids ranging 35–99 with gaps (38 of those 65 ids absent)

Secondary, unrelated to the panel: .highwatermark drift

In the same task directory, .highwatermark contains 94 (2 bytes, no newline) while 95.json–99.json exist and 94.json does not. Its mtime is 3m16s after 95.json was created, and it was never rewritten afterwards: 96–99 were created roughly 42 hours later with the watermark still at 94.

No harm observed — 96–99 were allocated correctly regardless, so the allocator does not rely on the watermark alone within a live session. Filing it here rather than separately in case it shares a bookkeeping path; happy to split it out if preferred.