Opening an archived session shouldn't disturb the agent it belongs to

[dwyanewang]

What I'm trying to do

Go back through an archived session to re-read what an agent did — usually from my phone, looking for the context around a change I made days ago. Archived sessions are where most of my history lives, so I open them often and I open several in a row.

How I do it today

Open the archived session in Paseo and scroll its timeline.

Where Paseo gets in the way

Opening an archived session does not just read it — it reopens the underlying provider session.

Every archived session I open leaves a provider session running. Opening one registers a live interactive session that nothing ever closes: the archived load path has no close, and there is no idle reclamation. For Codex that is a codex app-server child process; for Pi, OMP and ACP a runtime plus temporary MCP/extension files. Browsing ten old sessions leaves ten of them behind until I restart the daemon. On a laptop I notice this; on a machine I'm remoting into, it just quietly piles up.

With Codex it also disturbs the thread itself. Reading archived history resumes the native thread and claims its writer lock. After that, archiving that thread — from the Codex CLI or from Paseo — fails with already has an active writer. So looking at history changes what I can do with the session afterwards.

With OpenCode, closing the tab afterwards aborts the session. The teardown issues a session.abort, and OpenCode's abort is session-scoped rather than turn-scoped, so it cancels whatever that session is running. OpenCode's archive flag is only a timestamp field and does not stop a session from running, so an archived session can legitimately be busy — for example if I'm continuing it in a terminal.

I hit the first one constantly because it needs nothing but opening a session. The other two need the session to still matter to me, which is exactly when I care.

What the flow would look like if it worked

Opening an archived session reads its history and nothing else: no resume, no change to native archive state, no abort, and any temporary process released as soon as the read returns. Reopening old sessions should be as cheap and as harmless as scrolling.

Evidence

I checked these against real provider binaries rather than reasoning from the code, since all three are about what the provider process actually does:

• Codex, real codex 0.153.4: after a history read, archiving the thread fails with thread … already has an active writer — the read resumed it. A spawned codex app-server is also still alive after the read returns.
• OpenCode, real opencode serve 1.14.46 behind a recording proxy: one history read plus a tab close sends exactly one session.abort.

Both are reproducible without credentials or with any OpenAI-compatible endpoint.

A related thing I ran into while checking: archiveAgentUnlocked syncs the native archive before it closes the runtime, so thread/archive loses to the thread's own writer lock and the best-effort catch swallows it. A Paseo-archived Codex agent therefore usually leaves its native thread active. Happy to file that separately if it's worth its own thread.

Prior attempt

I put an implementation up as #4473 (previously #2388, closed). Posting this as a discussion because the contributing guide asks for the workflow behind a change, and I'd rather hear whether this framing is even the right problem before that PR is worth anyone's review time. Entirely fine if the answer is "not now" or "not this shape".