[bug] Terminal history is session-scoped, and every finished run ends the session — so history looks lost while sitting in D1

[serge-ivo]

The complaint

Why do I always see "Start a session" in the Terminal tab? Why do sessions expire all the time?
I should see history in the terminal forever — it should be from the DB, not streamed like tmux.

Correct on every point. The history is in the database. The UI just cannot reach it.

Why sessions keep ending

Three callers of endSession, two of them automatic:

1. workflows/coding-session.ts:447 — the Pilot ends the session when its run finishes. Every
   start_work / Loop run closes the session on completion (ended, or error on
   failed/max_steps). So finishing work is what removes your terminal.
2. lib/coding-store.ts:437 — the orphan reaper. Any active session the runner is not
   tracking, older than a 3-minute grace, is marked ended. Every pags up restart reaps them.
3. routes/coding.ts:1384 — the explicit Kill, which is the only one the user asked for.

Live example: FWS platform Coder had 13 sessions, all ended/error, 0 active — with a healthy
runner online.

Why the history looks lost

It is not lost. coding_timeline (migration 0023) is append-only and stores exactly what is
wanted — terminal, command, chat_user, chat_assistant, brain, outcome — in D1.

The problem is scoping:

session_id  TEXT NOT NULL REFERENCES coding_sessions(id),
instance_id TEXT NOT NULL REFERENCES agent_instances(id),
...
CREATE INDEX idx_coding_timeline_session      ON coding_timeline(session_id, seq);
CREATE INDEX idx_coding_timeline_session_type ON coding_timeline(session_id, type, seq);

Both indexes are per session. instance_id is on the row, so a per-instance or per-repo read
is perfectly possible — nothing asks for one. The Terminal view renders the open session's rows,
and with no open session CodingTab.tsx:840 renders "No session running / Start a session"
instead of any history at all.

So each completed run starts a fresh session id, a fresh empty timeline, and the previous work
becomes unreachable through the UI while sitting intact in D1.

What it should be

Terminal history should be a property of the repo, not of a session:

• Read the timeline by (instance_id, repo) and render it continuously, with session boundaries
  as separators rather than as the unit of retrieval. An index on (instance_id, seq) makes this
  a one-line query change.
• Show history whenever it exists, with "Start a session" as an action alongside it, never
  instead of it. (Same shape as [bug] Coding tab's offline state is unrecoverable — it hides the only control that could clear it #241, where the offline message replaced the only control that
  could clear it.)
• Reconsider (1) above: does a finished Pilot run need to end the session, or only mark the run
  done? Ending it is what forces a new session — and therefore a new empty timeline — for the next
  piece of work on the same repo.

Verification

• Finish a Loop run, stay on the Terminal tab: the transcript remains.
• Restart pags up: history survives, and starting a new session appends rather than replaces.
• Open a repo with no live session: previous output is visible, with a Start action available.

[serge-ivo]

Verified TRUE, every line including the SQL. Fixed in 27f4c4e.

Confirmed:

• Three endSession callers, two automatic — workflows/coding-session.ts:447 (the Pilot, in its finally, ended or error on failed/max_steps), lib/coding-store.ts:437 (the orphan reaper, 3-min grace), routes/coding.ts Kill. Exactly as described.
• Migration 0023 creates only idx_coding_timeline_session (session_id, seq) and idx_coding_timeline_session_type. instance_id is on the row and nothing reads by it.
• CodingTab.tsx solo view renders "No session running." + "Start a session" and nothing else when openSession is null.

So: "finishing work is what removes your terminal" is precisely right, and the history was intact in D1 the whole time.

What shipped

1. Migration 0077 — CREATE INDEX idx_coding_timeline_instance ON coding_timeline(instance_id, seq). No repo column added: the repo is coding_sessions.repo_id, one join away, and denormalising it would create a second copy of a fact that can then disagree with the first.
2. loadRepoTimeline(env, {instanceId, userId, repoId, limit}) — joins coding_sessions, owner-scoped in the SQL (this is reached from a repo id; a repo that is not the caller's must return nothing even if a future route forgets to check). ORDER BY seq DESC LIMIT n then reversed — ascending-with-limit would keep the oldest rows, so a repo with long history would show its first session forever and never the run that just ended.
3. GET /v1/instances/:id/coding/repos/:repoId/timeline — never 404s for want of a live session.
4. Console — the empty state is now an action strip (Start a session · runner warning) above a RepoHistory transcript, exactly your "alongside it, never instead of it" / [bug] Coding tab's offline state is unrecoverable — it hides the only control that could clear it #241 shape. Session boundaries are sticky separators, which is the inversion that matters: a session is now a boundary in the history, not the way you ask for it. Grouping/filtering is pure in repo-history.ts — it groups consecutive runs of sessionId rather than keying a map, because the stream is already seq-ordered and grouping by key would silently reorder interleaved sessions (two machines, or a session reclaimed onto another node) into an order that never happened. Chat turns are filtered out; commands/brain/outcome kept.

Your third bullet — left deliberately

I did not change the Pilot to stop ending its session. It is what releases the driver claim (endSession clears driver_id, and it is documented as "the ONE place a session leaves active", #206) and what closes the board card; a run that finishes without it would strand a claim and lock the repo out of future runs. That was only painful because ending the session destroyed reachability of the history — which is now fixed at the layer where it was actually wrong. Happy to revisit if a new session per run still feels wrong once the transcript is continuous.

Verification 1 and 3 from the ticket are now true. Verification 2 (pags up restart) follows from the same change — the reaper ends sessions, it never deletes timeline rows — but I have not run it against a live runner, so treat that one as reasoned rather than observed.

15 tests in coding-timeline.test.ts (4 new), 10 in repo-history.test.ts.

[serge-ivo]

The consequence is sharper than "history looks lost" — delegation is single-use

Confirmed live today. Combine two facts already in this issue and in loop-drivers.ts:

1. codingDriver.start requires a live session — loop-drivers.ts:116, 409 with "has no live coding session" otherwise.
2. coding-session.ts:447 — the Pilot ends the session when its run completes.

So every delegated job destroys the session it needed:

you start a session manually
  → ask the agent to do something
  → start_work runs, Pilot completes
  → Pilot ends the session
  → ask again → 409 "no live coding session" → start another by hand

Observed end to end on FAS (964594b6): session opened 03:44:50, start_work at 03:45:23, Pilot closed it 03:45:36. A retest two hours later with the runner healthy returned the 409.

Delegation therefore works exactly once per hand-started session, which also explains the user report that opened this issue ("why do I always see Start a session") and why the Coder Lead could not delegate to any of four agents (#259).

Worth deciding explicitly as part of this: should a completed Pilot run end the session, or only mark the RUN done and leave the session idle-but-live for the next goal? Ending it is what makes the session single-use, forces a new empty timeline each time, and turns a supervisor into something that cannot supervise without a human opening a session first.