Repository navigation
(sessions): an attached background session is missing from the sidebar until it runs a turn #620
Description
Observed (maintainer, 14/10 ~02:40 local, v0.0.94)
A conversation running in the background (supervision-locale, sessionId e7abbcdc-86dd-439d-8232-f890f3aa05bc, cwd C:\Serveur\supervision) was attached from Switchboard. Its row did not appear in the sidebar. It appeared only after the session ran one turn.
Expected
The row is listed (and selected/marked open) as soon as the attach tab exists.
Side observations, reported by the attached session itself (relation unknown)
- At the same moment, its additional working directory
C:/Serveur/supervisionwas removed from its environment and its scratchpad was announced as no longer available. - No file under
~/.claude/sessions/*.jsoncontained that sessionId at check time. - Its session-only crons survived.
Leads, not verified
- The sidebar row may be keyed on a transcript write (first JSONL append after attach) or on a descriptor that a
--bgworker does not write under that id; until either exists, the open tab has no row. - The attach may restart the worker with a different environment (lost
--add-dir), which would be a CLI-side effect of attach rather than Switchboard's, to be measured. - Relates to (sessions): send a running session to background and bring it back, so it survives a Switchboard restart #546 / (sessions): send a local tab to the background and keep it open as an attach tab (#546) #612 (attach tabs for backgrounded sessions) and to the row definition of (sidebar): define what a row represents and make every row verb follow it #564.
Repro to build
Background a session with an additional directory, attach it from the Agents view without sending anything, check the sidebar and the job's state.json / descriptor before and after the first turn.
Activity
devsuitup commentedon Oct 14, 2026
Follow-up from the same session (14/10): going to the background loses its file context.
C:/Serveur/supervision(the session's own project dir) and said the scratchpad announced earlier is no longer available.%TEMP%\claude\C--Serveur-supervision\e7abbcdc-86dd-439d-8232-f890f3aa05bc\scratchpad, 256 entries. Nothing was deleted; the session just lost the right to use it, so its notes are orphaned and a second store starts.Likely cause, from the #546 measurement (CLI 2.1.296), not yet confirmed for this case:
/backgroundstarts a worker with--session-id <new> --fork-session --resume. The scratchpad path is keyed by session id, so the worker gets a new one; the worker command line carries no--add-dir, so added directories are dropped. If so this is Claude Code's background mode, not Switchboard, and Switchboard cannot re-announce the CLI's scratchpad.To measure: the worker's full command line and environment after
/bgof a session started with--add-dir; whether a session backgrounded through Switchboard's Send to background (#612) behaves the same.Options to evaluate after measuring: report upstream (keep the scratchpad / re-pass
--add-diron fork); on the Switchboard side, at most warn before sending to background that added directories and the scratchpad will not follow, or re-add the directories on attach if the CLI exposes a way.devsuitup commentedon Oct 14, 2026
Correction (measured by the same session, 14/10): nothing was lost. The cwd is still
C:\Serveur\supervision; the old scratchpad and the project dir are both readable and writable (write, read, delete of a test file).Only the model's context changed: an environment notice told it the extra working directory was removed and the scratchpad was no longer available. The real risk is a session that obeys the notice, abandons a working store and starts a second one.
Those notices are Claude Code's own environment-update messages; Switchboard does not write them. So the context-loss part is upstream (the background/attach transition announces a removal that did not happen). The Switchboard part of this issue stays the missing sidebar row.
devsuitup commentedon Oct 14, 2026
Third observation (maintainer, 14/10 ~02:50 local, v0.0.94): no background session shows the "bg" marker next to its name in the sidebar any more, for any session. Possibly the same defect (background state not reflected until a turn runs); not verified. The indicators audit of 14/10 (.work-files/audit-indicators.md) also found the descriptor of a bg session frozen at
busywhile its job kept updating: the marker source should be checked against the job files (jobs/<id>/state.json), not only descriptors.devsuitup commentedon Oct 14, 2026
Item 5 (measured by supervision-locale, 14/10): the sidebar shows the launch name instead of the user's rename.
claude.exe --session-id 88e0b0ef-9016-463c-8a7c-549a9cc5b219 --fork-session --resume <...\e7abbcdc-....jsonl> ... --name "supervision-locale (3)".~/.claude/sessions/23408.jsonsaysname: supervision-locale,nameSource: user: the rename reached Claude Code. The sidebar keeps "supervision-locale (3)".--name "switchboard-dev (2)", registry saysswitchboard-dev/user.To decide in the fix: the displayed name of a live session should follow the registry's
namewhennameSourceisuser, not the launch argument (not yet verified which one the sidebar reads).Related consequence:
--fork-sessiongives the resumed conversation a new id (88e0b0ef, not e7abbcdc). Anything keyed on the old id points at a transcript nobody writes any more. On the Switchboard side, trigger routing re-keys on a provable continuation (#579, ADR 0003) and #564 merges a proven linear chain into one row; the attach/sidebar fix must use the same chain so the row, its name and its "bg" marker follow the new id.(sessions): list an attached background session at once, mark it bg a…
(sessions): mark bg rows from live job state and let a Switchboard re…
(bg): rebuild the Agents roster only for subscribers and notify the s…
(sessions): list an attached background session at once, mark it bg a…