bug(pi): resume fails — promoted short session-id can't be resolved by --session (every follow-up errors "no agent_end")

[nathanschram]

Symptom

On the channelo auditor-pi Pi chat (cwd /home/nathan/auditor-toolkit/main), the first message in a fresh Pi session works, but every follow-up fails with (verbatim from Telegram):

error · pi · 4s
pi finished without an agent_end event
session: 019e4936 · resumed

(Two iPhone screenshots captured locally at incoming/file_7869.jpg and incoming/file_7870.jpg, sessions 019e491f and 019e4936.) Pi is effectively single-turn over Telegram — any second message in a session errors.

Repro: send 2+ messages in any one Pi chat. First works; second onward errors.

Root cause (confirmed from channelo logs + on-disk session files)

The resume token Untether stores and replays cannot be resolved by Pi's --session flag.

Three consecutive runs, chat -5017167845:

time	resume token	--session arg	result
16:26:19	(fresh)	/home/nathan/.pi/agent/sessions/--home-nathan-auditor-toolkit-main--/2026-05-21T06-26-19...+00-00_356a44a199d14842ae8ae3ac97343f86.jsonl (file path)	✅ AgentEnd, ok=True → then pi.session.promoted new=019e4936 old=<path>, session.resume.saved resume=019e4936
16:27:25	019e4936	--session 019e4936 (bare short id)	❌ rc=0 in ~1.5s, no AgentEnd → pi.stream.no_agent_end

So a working fresh run (resumed by path) gets its resume token overwritten with a short session id, and the next turn feeds that id to --session, which can't resolve it.

Why the short id can't resolve — two compounding defects:

1. Filename ≠ Pi's internal session id. _new_session_path (src/untether/runners/pi.py:612) names files with a uuid4 hex, e.g. ..._356a44a199d14842ae8ae3ac97343f86.jsonl, but Pi writes its own UUIDv7 id inside the file: 019e4936-af45-7124-8749-8fdb5350b045. Verified by comparison:

   • Native pi-created file: ..._019e48fe-8caa-70eb-86ae-f89cac979aca.jsonl → internal id 019e48fe-8caa-70eb-86ae-f89cac979aca (filename embeds the id).
   • Untether-created file: ..._356a44a199d14842ae8ae3ac97343f86.jsonl → internal id 019e4936-af45-7124-8749-8fdb5350b045 (no relation).

   Pi 0.74.1 --session <path|id> = "specific session file or partial UUID" — but it can't map 019e4936 back to the 356a44a1…-named file.

2. Truncation to a non-unique prefix. _short_session_id (src/untether/runners/pi.py:102-109) cuts the id at the first -, yielding 019e4936 — the UUIDv7 millisecond-timestamp segment. Sessions created close in time collide on it (the session dir shows many 019e48fd/48fe/4936… ids), so it's an ambiguous lookup key even when a match exists.

The promotion (_maybe_promote_session_id, pi.py:112-126; introduced/refined in dd31bbf and 8cf4246) was meant to produce a short, typable resume line — but the promoted value is fed straight into --session on the next turn (pi.py:462-465), where it doesn't resolve. The footer resume line pi --session 019e4936 is broken for users for the same reason.

Affected code

• _maybe_promote_session_id / _short_session_id — src/untether/runners/pi.py:102-126
• build_args --session branch — src/untether/runners/pi.py:462-465
• _new_session_path filename scheme — src/untether/runners/pi.py:612-625
• new_state — src/untether/runners/pi.py:492-500

Proposed fixes (choose/validate)

• (A, recommended) Resume by the file path Untether already owns. Stop overwriting the resume token with the short id; persist the session file path as the resume token and pass --session <path> every turn (path form is explicitly supported and provably works above). Keep _short_session_id only for footer display, decoupled from the resume value.
• (B) Name session files by Pi's own id so partial-UUID resume resolves — harder, since the id isn't known until Pi emits the SessionHeader.
• (C) Don't truncate (promote the full UUIDv7) — insufficient alone, because the Untether filename still doesn't contain it; needs (A) or (B) too.

Guard/UX: on a resumed run, treat rc=0 + no AgentEnd as a clear "couldn't resume session" error (and/or fall back to --continue) instead of the cryptic "finished without an agent_end event".

Why this wasn't auto-caught

• Not a crash — rc=0, and pi.stream.no_agent_end is only a WARNING, so untether-issue-watcher error patterns don't file it. Follow-up: consider promoting pi.stream.no_agent_end on a resumed run to error-tier signal.
• Pi version split / suspected regression: channelo runs Pi 0.74.1; the dev-bot host (lba-1, @untether_dev_bot) runs Pi 0.72.1 (both advertise --session <path|id>). Promotion likely resolved under 0.72's partial-UUID lookup but stops under 0.74's — so Tier-1 integration on the older dev-bot Pi may still pass. Confirm by running a multi-turn Pi resume on dev-bot (0.72.1); test the fix on both versions. If 0.72 also fails, the bug is latent across versions and Tier-1 wasn't exercising Pi multi-turn.

Verification (for the fix)

• Unit (tests/test_pi_runner.py): build_args on resume passes a resolvable token; promotion no longer clobbers the resume value used for --session.
• Integration (@untether_dev_bot Pi chat): message, then a follow-up referencing the first — second turn must succeed and retain context. Confirm on channelo auditor-pi after rollout.

[nathanschram]

Why this surfaced now (and why CI never caught it)

Investigated the "how has this never happened before?" question. Short answer: it almost certainly did happen before — silently — and the test that should have caught it never actually verified context resume.

Confirmed

1. Not introduced by us. The Pi resume/promotion/filename code (_maybe_promote_session_id, _short_session_id, _new_session_path, build_args) last changed in 648051e (2026-02-24, takopi→untether rename). Unchanged since February. channelo has no special [pi] config and no session-index DB — config isn't a factor.

2. Pi U4 ("resume") was never a real context-retention test — from our own result files:

   • v0.35.3rc6 (Pi 0.72.1): U4 = "planned … tested via the natural resume token flow embedded in every Tier 1 run footer" — not actually run as a 2-turn context resume.
   • v0.35.2 (Pi 0.67.68): U4 = "✅ resume ok 10s", but the follow-up was a filesystem side-effect ("rename hello.txt → greetings.txt") — that succeeds with zero conversation memory because the file is on disk. "Resume ok" = "a second prompt ran and did the thing," not "context carried over."
   • Unit test_session_id_promotion_from_stdout (tests/test_pi_runner.py:148) asserts only that promotion produces the short id — never that it resolves a session. Green forever on broken-by-design behaviour.
   • Net: context-retaining Pi resume was never verified in any release.

3. Version split: Pi 0.67.68 (v0.35.2) → 0.72.1 (v0.35.3rc6, current dev-bot) → 0.74.1 (channelo now). Integration always runs on the older dev-bot Pi; channelo is the only host on 0.74.x.

Contributing factors (need 2-turn confirmation, not yet proven)

• UUIDv7 ids (Pi changelog [0.67.1] "newly generated session IDs to use UUIDv7"): _short_session_id splits on the first -, so for UUIDv7 the segment (019e4936) is a millisecond timestamp shared across same-window sessions — not a unique key. Caveat: 0.67.68 was already post-UUIDv7 yet U4 "passed," so this is contributing, not proven as the sole trigger (that "pass" was likely the false-pass above).
• channelo aggravator: several Pi sessions created in a rapid setup burst (019e48fd/48fe/4936 within ~1 min) → maximal prefix collision.
• 0.74 escalation: 0.74.x reworked /resume relationships + path canonicalisation; channelo now hard-errors (rc=0, no agent_end, ~1.5s) where older Pi likely lost context silently. (Exact per-version behaviour not yet confirmed.)

Implications for the fix

• Reinforces fix (A): resume by the file path Untether owns, decoupled from the short display id — don't rely on Pi resolving a promoted id at all.
• Close the test gap: resume integration tests must assert context retention (turn 2 asks something answerable only from turn 1's memory, e.g. "what's in the file I just asked you to create?" with no filename) — not a filesystem side-effect. Add a unit test that the resume value fed to --session round-trips to a resolvable session.
• Decisive confirmation still pending: a 2-turn context test on dev-bot (0.72.1) vs channelo (0.74.1). Expectation: dev-bot loses context silently (still "answers"); channelo hard-errors.

[nathanschram]

⚠️ Correction — the root-cause mechanism above is WRONG; re-scoping this issue

After a user report that a plain 2-turn hello.txt resume worked fine, I reproduced the exact failing command on channelo. The earlier "promoted short session-id can't be resolved by --session" mechanism is incorrect.

Experiment (channelo, Pi 0.74.1, project ~/auditor-toolkit/main)

Test	Result
pi --print --mode json --session 019e4936 "hi" (the exact bare short id)	WORKS — resolves session 019e4936-af45-…, full event stream, rc=0
Same, under Untether's exact filtered env (CI,HOME,LANG,NO_COLOR,PATH,SHELL,USER)	WORKS
Same + a prompt that actively calls PAL/Trello/Brave/JINA MCP tools	WORKS — 8 tool executions, agent_end, rc=0
--session <abspath> and --session-dir <global> --session <id>	both WORK

So: Pi does match the partial id against the internal header id even when the filename is a different uuid4. Filename≠id, UUIDv7-prefix truncation, session-dir mismatch, and env-filtering are all ruled out as the cause. The failure does not reproduce now.

What actually happened (best current understanding)

The failing production runs died in ~1.5 s emitting zero events (session.summary.no_events) — a startup failure, not a resume-resolution or tool-execution failure. At that time Pi reported "MCP: 0/8 servers" (zero live MCP connections); MCP servers connect and execute fine now. The repeated errors were real but transient, most plausibly Pi failing at startup while MCP servers weren't connecting during the user's active Pi/MCP setup window — since resolved.

Re-scope (keeping this issue open)

The genuinely confirmed, actionable defect is a diagnostics gap, not resume:

1. Untether is blind to why Pi exits. On rc=0 + no agent_end, the stream_end_events path swallows Pi's stderr and shows the cryptic "pi finished without an agent_end event". That's why the real cause was invisible from Telegram. Fix: capture + surface a tail of Pi stderr on the no-agent-end path; distinguish rc=0 + zero events (startup/early-exit) from a genuine truncated stream.
2. Promote pi.stream.no_agent_end on a resumed run to error-tier in untether-issue-watcher.
3. (Separate, still true) Pi resume context-retention has never been genuinely integration-tested — U4 historically verified a filesystem side-effect, not memory.

Do NOT implement the earlier fix options (A/B/C) — they target a non-bug. Suggest renaming this issue to something like "pi: surface stderr / diagnose silent rc=0 no-agent_end exits" and watching for recurrence of the startup failure.

Apologies for the earlier over-confident root cause — corrected here with reproduction evidence.

[nathanschram]

📌 Resolution / for-the-record (2026-05-21)

Recording the full arc so this isn't re-investigated from scratch.

What was observed

On channelo's auditor-pi Pi chat (Pi 0.74.1), follow-up messages errored repeatedly with pi finished without an agent_end event · session: <id> · resumed (rc=0, ~1.5 s, zero events). It then "fixed itself" with no user action.

Investigation arc (and corrections)

1. First hypothesis (WRONG): promoted short session-id couldn't be resolved by --session. Filed with filename≠id / UUIDv7-truncation mechanism.
2. Reproduction refuted it: pi --session 019e4936 "hi" works — bare partial-id resolves against the internal header id, under Untether's exact filtered env, even with a prompt that fires 8 MCP tools. Session-dir mismatch and env-filtering also ruled out.
3. Per-run timeline (decisive): failures were resume-only, confined to 16:25–16:27. Fresh runs in the same window succeeded (16:01, 16:26). Resume works now with the identical command (17:10, 17:30). No config/version change in the window (pi binary, .mcp.json, settings, npm pkgs all settled ≤15:59); no malformed session files remain.

Best-supported explanation (transient, self-resolved)

A fresh run starts an empty session; a resume run reloads/rehydrates the prior session — and the 16:26 session contained an MCP tool result. While channelo's 8 MCP servers were cold / "0/8 connected" during setup, re-establishing them during resume-load crashed Pi at startup (1.5 s, zero events). Fresh runs carried no MCP tool-state to rehydrate, so they survived the same window. Once the MCP servers warmed (npx packages cached + first successful connections), resume-load succeeded → working from 17:10 on.

Residual uncertainty: the MCP-rehydrate-while-cold mechanism is inferred, not reproduced (the cold condition is gone). Certain: resume-only, transient, self-resolved, not the resume-token mechanism.

Current scope of this issue

Re-scoped from "resume bug" to the diagnostics gap that made this hard to diagnose:

1. Untether swallows Pi stderr on rc=0 + no agent_end (runners/pi.py:587 stream_end_events) → the real crash reason was invisible. Fix: capture + surface a tail of Pi stderr on that path; distinguish rc=0 + zero events (startup/early-exit) from a genuinely truncated stream.
2. Promote pi.stream.no_agent_end on a resumed run to error-tier in untether-issue-watcher.
3. (Optional) Detect "resume exited with 0 events in <2 s" and surface a "session may have failed to load / MCP servers cold" hint (and/or one retry).
4. (Separate, still true) Pi resume context-retention has never been genuinely integration-tested.

Do not implement the original fix options A/B/C — they target a non-bug.