ACP is stdio-only: every multi-tenant integrator rebuilds the same HTTP-to-stdio host (config.stream is not reachable from cordis.yml)

[chyroc]

Summary

@deepseek-ai/dsh-acp speaks ACP over stdio only. For a service that hosts DSH for many concurrent users, that means every integrator writes the same HTTP⇄stdio plumbing. We built it and it works, but it is the kind of thing that probably wants one good first-party answer instead of N private ones.

We run a multi-tenant agent platform with DSH as an inference backend and have real inference working through it, so the numbers below are from production-shaped use rather than speculation.

Current state

Transport is chosen in packages/acp/acp/src/index.ts:444-448:

const stream: Stream = config.stream ?? ndJsonStream(
  Writable.toWeb(process.stdout) as WritableStream<Uint8Array>,
  Readable.toWeb(process.stdin) as ReadableStream<Uint8Array>,
)

The config.stream seam (AcpConfig.stream, :77) is genuinely useful design and we lean on it — but note it is deliberately absent from the exported Config schema (:80-83, commented "Runtime-only transport override; production uses stdio" at :76). So it is reachable only by direct-mounting the bridge from TypeScript, not from a leaf cordis.yml, which is the only production config surface. In effect there is no supported way to host ACP over anything but stdio.

What an integrator has to build

To serve many tenants over HTTP against a stdio-only agent, we ended up writing:

• a supervised child process per harness, with startup/turn timeouts and restart handling;
• request multiplexing — many concurrent HTTP sessions over one stdin/stdout pair, keyed by ACP session id, plus reverse-request correlation for session/request_permission;
• session affinity, because a given ACP session id is only valid on the process that created it — this constrains scheduling and makes rolling deploys interesting;
• a replay buffer with a bounded window and byte budget, so a client that drops its stream mid-turn can resume without losing committed output;
• heartbeats, because a long tool-running turn is otherwise indistinguishable from a dead pipe.

None of it is DSH-specific — any multi-tenant ACP host needs the same five pieces.

Ask

Either of these would remove the duplicated work:

1. A first-party streamable-HTTP ACP server, i.e. an acp-http sibling package that mounts the same bridge over HTTP with a documented session/stream model. The existing Stream abstraction means the bridge core likely does not have to change at all.
2. Or, much cheaper: promote stream to a supported extension point — document that hosting ACP on a custom transport is supported, and expose enough from the app layer that a deployment can supply one without vendoring acp-demo. Even just a short "hosting ACP on your own transport" section in packages/acp/acp/README.md plus keeping the seam stable would let integrators build on it confidently instead of guessing whether it is about to be trimmed as unreachable surface.

We would favor (2) as a first step since it is nearly free and unblocks everyone; (1) is the better long-term answer if you want ACP to be a serious remote boundary.

One caveat we would want your read on: the bridge's teardown contract is explicitly connection-owned (README.md:81, and the memoized quiesce at src/index.ts:450-510). A long-lived HTTP host wants per-session lifetime instead, which is the subject of a separate note we are filing on session/close.

Offer

We have the supervisor, multiplexer, replay buffer and heartbeat working and would be glad to contribute a reference acp-http package, or just the README section for (2) — whichever you would actually take. Happy to hear if hosting ACP remotely is out of scope by design, in which case documenting that clearly would itself save people time.

[denial123789]

The runtime-only Stream seam is useful, but a remote host still needs an explicit ownership model before choosing HTTP. The key invariant is principal -> tenant/policy revision -> child generation -> ACP connection -> Session -> request/reverse-request. Since rc.2 Session ids are connection-local and teardown is connection-owned, a restart must invalidate old handles rather than silently remap them, and a rolling deploy must stop admission before bounded drain. For unrelated tenants, one child per tenant or narrow trust domain is the safer default; multiplexing ids on one connection is routing, not isolation. We turned this into topology choices, a gateway resource model, reconnect/replay semantics, security minimums, and fourteen acceptance tests: https://sandbaseai.github.io/deepseek-harness-handbook/acp-remote-hosting.html

Disclosure: I contribute to this independent community handbook.