[dsh-acp] ACP clients cannot rebuild a session transcript: no session/load, and session/resume does not replay history

[zheng1]

Summary

dsh-acp is advertised as an automation-only surface, and its README lists session/load among the unsupported calls. Because session/resume also restores a session without replaying its updates, a standard ACP client has no way to rebuild a session transcript after its own process restarts — even though the harness keeps that transcript on disk. The model keeps its full context; only the client's view of the conversation disappears.

This post asks whether transcript replay can be supported, or whether there is a supported way for a client to rebuild a transcript that I have missed.

What a client expects

ACP's session/load is the standard way for a client to reopen a persisted session: the agent replays the session as session/update notifications before returning the session state, so the client can render the history. Clients that resume a session and only get future updates end up showing an empty conversation next to an agent that still remembers everything.

What I observe (dsh 0.1.5-rc.1, same on 0.1.2-rc.1)

initialize advertises list/resume/close, and no loadSession:

{
  "protocolVersion": 1,
  "agentInfo": { "name": "deepseek-harness-acp", "version": "0.0.1" },
  "agentCapabilities": {
    "mcpCapabilities": { "http": true },
    "promptCapabilities": { "image": false, "audio": false, "embeddedContext": false },
    "sessionCapabilities": { "close": {}, "list": {}, "resume": {} }
  },
  "authMethods": []
}

A fresh process that calls session/resume with a session id from a previous run receives the session state and then no session/update traffic for the earlier turns. The turns are on disk — in my case a session log of 856 KB / 1404 records (~/.dsh/sessions/<escaped-cwd>/<session-id>/session.v3.jsonl.zstd) — and a prompt sent to the resumed session clearly has the full prior context. The client just cannot see it.

Reproduction:

1. dsh --profile acp (stdio), initialize → note the missing loadSession.
2. session/new, send one or two prompts, observe session/update.
3. Stop the process. Start it again, initialize, then session/resume with the same session id.
4. Only new updates arrive; the previous turns never reach the client.

Impact

I am the author of a Paseo provider integration (getpaseo/paseo) that drives dsh --profile acp. Paseo's design states that the provider transcript is the durable authority and a resumed agent rebuilds its timeline from it (that is how its Claude/Codex/OpenCode/Pi adapters work), and its ACP adapter replays history only when the agent advertises loadSession:

if (this.agentCapabilities?.loadSession) {
  this.replayingHistory = true;
  await this.connection!.loadSession({ sessionId, cwd, mcpServers });
} else if (sessionCapabilities?.resume) {
  await this.connection!.unstable_resumeSession({ sessionId, cwd, mcpServers });
}

For DeepSeek Harness this takes the second branch, so after a client restart the conversation renders empty while the agent still answers with full knowledge of it. That is a confusing state for users, and it is the only provider I integrate where a long-lived session becomes invisible this way. Any editor-style ACP client that offers session history would hit the same wall.

Ask

Either of these would resolve it, and I am happy to test a build:

1. Support session/load per the ACP spec (replay the persisted turns as session/update, then return the session state). This is the interoperable option and requires no client-side knowledge of your log format.
2. Or replay on session/resume behind an opt-in flag (for example a _meta or parameter the client sets), keeping the default behavior automation-friendly.
3. Or document a supported way to rebuild a transcript if replay is intentionally out of scope. Reading ~/.dsh/sessions/**/session.v3.jsonl.zstd from the client works, but it couples clients to an internal, versioned file format (v3 today), which I would rather not ship.

Context for why I am not asking for anything else on this surface: modes, commands, plans, and terminals being absent is fine for automation — resume-without-history is the one that makes a persistent session unusable from the client that created it.

[zheng1]

Update: a working prototype exists.

Since dsh-acp exposes no extension seam for another plugin to wrap (it only consumes services), the only way to add this today is to replace the bridge. I forked @deepseek-ai/dsh-acp at tag dsh-v0.1.5-rc.1 and added two pieces:

• initialize advertises loadSession: true;
• session/load opens the stored session with a read-only persistence handle (ctx.sessionPersistence.open(id, 'read')), resumes it exactly as session/resume does, and replays the snapshot through the existing updates.ts mapping before returning.

The bridge is 1822 lines; the change is ~142 (~75 in src/index.ts, plus a new 65-line src/replay.ts).

Repo (MIT, dsh-plugin topic): https://github.com/zheng1/dsh-acp-replay

Verified on dsh 0.1.5-rc.1 with a scratch DSH_HOME and a real key:

loadSession advertised: true
session/new + two prompts  ->  end_turn
# then, in a brand-new process:
session/load -> {"user_message_chunk":2,"agent_message_chunk":2,"usage_update":2}
user texts:  ["Reply with exactly: ALPHA", "Reply with exactly: BETA"]
agent texts: ["ALPHA", "BETA"]

Two observations worth passing on regardless of what you decide for this feature:

1. Injected context shares user/message. The runtime-context snapshot and the available-skill list are committed as user/message events next to real prompts. A replay that maps every user/message to a user turn renders harness-injected text as if the user had typed it; filtering on source.kind === 'user' is what makes the replayed transcript match the conversation. Any future upstream replay needs the same care.
2. The persistence read API moved between releases. In 0.1.5 the service exposes create/open/flush/stat/list, and a handle read is the way in (open(id, 'read'), then read(0)); 0.1.2-rc.1 exposed load/inspect/readFrom on the service itself. A client- or plugin-side transcript reader therefore pins itself to a version, which is the other reason handing this to the bridge is better.

If the team would rather own this, the change is confined to two call sites plus one mapping module and I am glad to hand over the exact diff. Otherwise this community bridge is the fallback — with the caveat that it must be rebased against dsh-acp on every release, which is exactly why an upstream implementation remains the better answer.

[zheng1]

Added the client-side evidence, since "does it actually fix the client?" is the question this needs to answer.

End to end through a real client (Paseo 0.7.2 daemon, dsh 0.1.5-rc.1, two DSH providers configured on the same daemon so the bridge is the only variable). Each agent ran one prompt; then the daemon was restarted — the event that used to erase the visible conversation:

Provider	Before restart	After restart
this bridge (loadSession advertised)	user prompt, answer, reasoning row	all three rows restored
shipped bridge (no loadSession)	user prompt, answer	No activity to display.

The client needed no change: its ACP adapter takes the loadSession branch only when the agent advertises the capability, then primes its timeline from the replayed updates. Same result in production on a host where the provider was switched to this bridge and the daemon restarted.

Also hardened the prototype for the version skew this thread is partly about. The bridge now refuses to mount when the harness does not offer the calls it needs, and says why:

dsh-acp-replay cannot serve session/load in this harness (harness 0.1.6):
  - needs ctx.sessionPersistence.open(), but the mounted sessionPersistence service exposes inspect, list, load, stat
This plugin vendors @deepseek-ai/dsh-acp@0.1.5-rc.1 and needs the persistence handle API it introduced.
Use the shipped bridge instead ("dsh --profile acp"), or update this plugin for the installed harness.

test/selfcheck.mjs runs initialize alone and reports whether loadSession is advertised, which is what to run after a harness upgrade; test/compat.test.mjs covers the guard's behaviour. Everything is in the repo: https://github.com/zheng1/dsh-acp-replay

None of this changes the ask: a vendored bridge has to be rebased on every dsh-acp release, so the upstream implementation — replaying the persisted log as session/update before session/load returns, filtering user/message on source.kind === 'user' — remains the better outcome for every ACP client, not just this one.