A finished coding run is unauditable over MCP — 13 coding tools, none reads coding_timeline, and coding_session_capture answers an ended session with an empty pane

[serge-ivo]

The gap

An autonomous coding run's conversation with the engine is persisted forever in coding_timeline (migration 0023, append-only, seq-ordered) and served by GET /v1/instances/:id/coding/sessions/:sid/timeline. No MCP tool reads it. So the one surface built for auditing an agent — the MCP server, whose agent_trace description calls itself "the primary tool for debugging or improving an agent" — cannot see what an agent actually said to a coding CLI once the session has ended.

Measured

Thirteen coding_* tools are registered (grep -o '"coding_[a-z_]*"' workers/mcp/src):

coding_diagnostics · coding_loop_start · coding_loop_status · coding_loop_stop · coding_overseer · coding_repo_add · coding_repos_list · coding_session_capture · coding_session_end · coding_session_fresh · coding_session_message · coding_session_restart · coding_sessions_list

None reads the timeline. The closest, on an ended session:

coding_session_capture(instance_id: "bd43f4de-…", session_id: "csess_92b2130d-…")
→ { "sessionId": "csess_92b2130d-…", "runState": "idle", "pane": "" }

csess_92b2130d is a real 6-minute run with 5 Pilot instructions and a push to main. The tool answers with an empty pane and idle, which is indistinguishable from a session that never did anything.

agent_trace does not fill the gap either. On this instance, 186 events: 149 from chat, and all 33 coding-source events are act.consequential — the consequential-act record (#294), not the instruction stream. So the trace can tell you a run pushed to main; it cannot tell you what the run was told to do.

coding_sessions_list returns the session rows, so an MCP client can name the sessions it cannot read.

Why it matters, concretely

This is not hypothetical scope. Auditing #505's post-fix recurrence required reading the exact instructions the Pilot sent — the byte-identical ## Testing block across steps 3/4/5 and the escalation to "the project owner has explicitly requested this exact wording". Every one of those facts came from the REST route with a hand-made curl and the CLI's session token. Over MCP the run is a black box: three chat messages saying **Loop → engine** (step N): followed by the first 120 characters of the instruction (describe() in lib/coding-loop.ts truncates there before it reaches chat), and nothing else.

Every finding in that audit that concerns what the Pilot said is therefore unreachable from the surface the platform offers for exactly this purpose.

What to do

Register coding_session_timeline as a thin proxy — the same shape as list_instance_tools, which is nine lines around authedCall:

coding_session_timeline(instance_id, session_id, limit?)  → GET /v1/instances/:id/coding/sessions/:sid/timeline

Scope read, no confirmation, no dry run. It belongs in workers/mcp/src/instance-tools/coding.ts beside coding_session_capture, and needs a row in contract.test.ts's per-tool table (["coding", "read", null, null, "instance_id,session_id,token"]).

Two details worth deciding at write time:

• Say in the description what capture cannot do. coding_session_capture's own text should point at the timeline for an ended session, otherwise the next caller reads pane: "" as "nothing happened" — the same class of silent-false-answer as [bug] The model writes its own tool RESULTS and the platform believes them — invented GitHub issues and file contents reported as fetched, raw markup left in the message #395/[bug] A local repo is marked "ready" without anyone checking it exists — an empty checkout reports success, and the agent invents the code it cannot see #405.
• limit / paging. A 26-step run returns 26 rows of up to ~1KB plus deduped terminal snapshots; a long one will not fit an MCP response. Default to the most recent N with a cursor, rather than truncating silently.

Alternatives rejected

• Extend agent_trace to carry the instruction stream. The Pilot already writes each instruction to coding_timeline as a command row (coding-session.ts, the driven branch, per [bug] The Coding tab's Loop is still a browser poll — so merge authority, the driver claim and the spend budget all miss it #374) — duplicating it into agent_events writes the same fact twice, and [bug] The Coding tab's Loop is still a browser poll — so merge authority, the driver claim and the spend budget all miss it #374's whole point was that the timeline is the durable record. The trace should stay the cross-source index.
• Tell people to use the REST route. It works and I used it, but it needs the CLI session token and a hand-built URL. The MCP surface exists so an agent or an operator can audit without that, and it already exposes coding_sessions_list, coding_session_capture, instance_activity and agent_trace — the timeline is the one hole in an otherwise complete set.

Acceptance

• coding_session_timeline on csess_92b2130d-… returns the five command rows with their full text, in seq order.
• coding_session_capture's description tells a caller where to look for an ended session.
• contract.test.ts covers the new tool's scope/confirmation/dry-run row.

Regression risk

Low — a read proxy over an existing owner-scoped route. The one thing to get right is response size: an unbounded timeline can exceed the MCP client's token budget, which turns a debugging tool into a wall of truncated JSON.

[serge-ivo]

Satisfied by one tool, shared with #581 — da4bcec

This issue and #581 are "one tool apart" exactly as the body says, so it is one tool:
coding_timeline, registered in instance-tools/coding.ts beside coding_session_capture,
scope read, no confirmation, no dry run. Live: /health reports 136 tools.

Named coding_timeline rather than the proposed coding_session_timeline because session_id is
optional — the tool answers at instance level too, which is what makes one reader serve both issues.

The finished-run case specifically

Resolution order is: the session_id you name → else the newest active session → else the
most recently updated one. That last fallback is what makes this your issue's answer: the platform
ends sessions by itself constantly (the Pilot closes one on every finished run), so a run that
finished a minute ago has no active session at all. A test drives exactly that — an ended session
with a command and an outcome row, read back with no session id.

An ended session reports runState: "ended", not the runner's idle. Your measurement —
csess_92b2130d, a real 6-minute run with 5 Pilot instructions and a push to main, answering
{"runState":"idle","pane":""} — is a reading nobody took: the pane lives on the runner and there
is nothing to capture once the session ends. Reporting idle there was a false statement about a
finished run.

Both "two details worth deciding at write time"

• coding_session_capture's description now says what it cannot do, and names this tool:
  "LIVE sessions only — the pane lives on the runner, so an ENDED session answers with an empty
  pane and idle, which does not mean nothing happened. To read what a run did, or to follow one
  while it works, use coding_timeline." This was the [bug] The model writes its own tool RESULTS and the platform believes them — invented GitHub issues and file contents reported as fetched, raw markup left in the message #395/[bug] A local repo is marked "ready" without anyone checking it exists — an empty checkout reports success, and the agent invents the code it cannot see #405 silent-false-answer class you
  flagged.
• limit / paging: a real cursor, not silent truncation. since_seq is an exclusive seq,
  default 40 rows, and — because a row cap cannot bound bytes — a second bound at 40,000 serialised
  bytes. Terminal snapshots come back as a 400-char tail with chars giving the true length rather
  than being dropped or inlined. 79 rows of production-max panes measure 40,304 B on the deployed
  tool against a 65,536 B limit.

What it will NOT give you

Your audit needed "the exact instructions the Pilot sent" — the byte-identical ## Testing block
across steps 3/4/5. That is exactly what a command row holds, verbatim and untruncated up to
1,200 chars (production mean: 427), so that audit is now reachable over MCP.

What is still not reachable is a structured per-tool-call argument/result log; content is free
text. See #581's AC7 comment for the full statement of that gap.

Closing this as delivered — reopen if the reader misses something your audit needed.