Resume renders empty transcript despite intact journal; identical tool-call repair re-runs on every load (repair result never persisted)

[bevis-wong]

Body

### Environment

- codewhale 0.9.13 (Rust TUI), linux x86_64
- provider: zai, model: GLM-5.3-Flash
- trigger: force-quit during a mid-run freeze (see related issue)

### Summary

After force-quitting a frozen run, `codewhale resume` restores nothing
visible although the on-disk session JSON is structurally intact. On every
load, `codewhale_tui::session_manager` logs the **identical** repair warning
for the same tool-call ids, so the repaired history is evidently never
persisted back to disk.

Reproduced on two independent sessions.

### Steps to reproduce

1. Hit the silent mid-run freeze described in the related issue.
2. Force-quit the TUI.
3. Run `codewhale resume` on the same session id.
4. Observe an empty transcript and repeated repair warnings on each load.

### Observed evidence (timestamps UTC)

Session A `a69916b2…`:

- Resume renders an **empty conversation**, even though the on-disk JSON has
  95 journal entries, a valid `leaf_id`, and an undamaged message parent
  chain (verified by reading the session store directly).
- Within ~35 seconds after startup, the same warning is logged **four times**,
  always repairing the same two call ids:

WARN codewhale_tui::session_manager: repaired persisted tool call/result history
session_id=a69916b2…
repaired_call_ids=["call_90fe91cb…", "call_2e5fc194…"]
duplicate_result_ids=[] orphan_result_ids=[]
(2026-09-15T02:29:34Z, 02:29:36Z, 02:29:49Z, 02:30:08Z)

- Session `metadata.updated_at` is touched at resume time, yet the visible
transcript stays empty.

Session B `53b16822…` (independent reproduction):

- After resume, the same warning appears twice for one call id:

WARN codewhale_tui::session_manager: repaired persisted tool call/result history
session_id=53b16822…
repaired_call_ids=["call_26c088d8…"]
(2026-09-15T03:28:01Z, 03:28:29Z)

This session *did* render its history afterwards, but the repair warning
repeating on each load shows the repair result is still not persisted.

### Expected

- Repairing interrupted tool-call pairs (missing tool_result for an
assistant tool_use) should happen **once** and be flushed back to disk.
- Resume should render the full transcript, including repaired entries.
- If the repaired history cannot be persisted, say so explicitly instead of
re-running the same fix on every load.

### Impact

Any force-quit during a long tool-heavy task can make a session unusable via
resume: the user loses interactive access to all prior work context and can
only recover it by hand from the session store.

### Related

- Force-quit is caused by the silent freeze issue (filed separately); this bug
is in the session load/repair/persist path and is independent of what caused
the freeze.

---
Sanitized log excerpts: see `attachment-issue-2-logs.en.md`.

attachment-issue-2-logs.en.md

[github-actions]

Thanks @bevis-wong for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[Hmbown]

Confirmed and taking this. The repeating identical repair warning is the tell: the repair result is computed on every load but never flushed back — and in session A's case the transcript renders empty despite an intact journal, which suggests the load path is bailing or filtering before render rather than the data being gone.

Investigating session_manager's repair path on v0914-chunk2 now. Will post findings here.

[Hmbown]

Thanks for this — the two-session evidence and the "reproduced on two independent sessions" note are what made it tractable. Splitting the report in two, because the halves have different answers.

(b) repair re-runs on every load — fixed, pending review

recover_session_for_resume repaired the dangling tool calls in memory and returned them, but no resume caller ever wrote the result back, so every load replayed the same repair and re-logged the same warning. Exactly as you inferred from the four identical warnings.

Fixed on branch v0914-chunk2 in 8c23842e9b — SessionManager::resume_session / resume_session_by_prefix persist the repaired record when recovery changed it, with an explicit warning if the flush fails (a failed write-back still returns the repaired in-memory session, so a read-only session directory degrades instead of breaking). That sits in PR #6175, which is open, not merged — so this is not in a release yet.

(a) empty transcript — not yet established, and we do not think it is the projection

Our first theory was that the history projection drops the recovered messages. We tried to verify that and it does not survive your own evidence: the repair appends a visible receipt ([tool_history_repair] Repaired N crashed tool call(s)…), and the history builder has an explicit case that renders exactly that string as a system cell. Your warnings fired, so the repair ran, so that receipt should have been on screen. An empty transcript means we never got that far.

What fits all three of your facts — empty screen, structurally intact JSON, repair warning still logged — is apply_loaded_session_with_goal returning Err before it touches history at all. The load (which logs the repair) precedes the apply; if the apply bails, nothing is rendered and nothing is written. There are six such early returns, and they surface only as a one-line status message:

Failed to restore session: <reason>

So the question that decides this:

When you resume and get the empty transcript, does the status line say "Failed to restore session: …"? If so, what is the rest of it?

If it does, the fix is in that early-return chain rather than in rendering. Two of those returns are strong candidates for your case specifically:

• the runtime-store host guard — this is bug(tui): session picker refuses saved sessions whose runtime store exists but is not the running host's own #6207, filed independently, and a force-quit is exactly what leaves a session bound to a store the next process does not own. We think Resume renders empty transcript despite intact journal; identical tool-call repair re-runs on every load (repair result never persisted) #6185(a) and bug(tui): session picker refuses saved sessions whose runtime store exists but is not the running host's own #6207 may be the same defect.
• restore_work_state, which is the likeliest A-vs-B differentiator, since force-quitting mid-tool-run is what leaves a dirty work state.

Your provider route (zai / GLM-5.3-Flash) also touches resolve_persisted_provider_identity, another of the six, so the route is worth ruling in or out.

If you still have session a69916b2…, the status-line text alone would settle it. No rush, and thank you for the force-quit detail — that was the link to #6207.

[Hmbown]

Verified done at the defect site on main (fix 8c23842):

• SessionManager::resume_session() (crates/tui/src/session_manager.rs:2429-2441) persists the repaired record so the same repair does not re-run on every load, and every resume path uses it (TUI startup, picker, LoadSession, exec --resume, ACP/runtime endpoints).
• AppAction::LoadSession hydrates through the manager for owned records and journal-projects + in-memory-repairs foreign files (crates/tui/src/tui/ui/apply.rs:1330-1353).
• Regression test resume_session_persists_repair_once (session_manager.rs:5509).

Note: the adjacent picker-refusal case (#6207, existing unheld store) is still open and in progress; resume acceptance will be re-tested after that lands. Ready to close for v0.9.14.

[Hmbown]

Fixed on main: 8c23842 persists the resume-time tool-call repair instead of re-running it on every load, so resume renders the repaired transcript.