Run a claude-code-acp subprocess per structured session #134

New Issue

2026-09-03T10:36:12+01:00

naps62-yolo commented

2026-09-03 10:36:12 +01:00

New crate maestro-acp, wrapping the agent-client-protocol crate (crates.io,
maintained by Zed) in the client role. The daemon is the client; the adapter
is the server.

Spawning a session with view: Structured starts
claude-code-acp as a child process with stdio pipes, in the session's cwd, with
the session's env. The adapter is resolved on PATH; if it is missing the session
is created in a failed state carrying an actionable message naming the install
command, rather than a silently dead session. Document the install in
docs/INSTALL.md.

The handshake declares almost nothing. initialize reports fs.readTextFile,
fs.writeTextFile and terminal as false, so the adapter uses Claude Code's
own Read / Write / Bash instead of asking the daemon to act on its behalf. That is
what already happens in the terminal view, and it keeps the daemon out of the
business of enforcing a filesystem boundary. session/request_permission is the
one client method that gets a real implementation, in #7.

Then session/new with the session's cwd, and hold the returned ACP session id in
the sidecar so a later respawn can session/load it.

Kill and daemon shutdown both terminate the child: DELETE /api/sessions/:id sends
session/cancel, waits briefly, then SIGTERMs. The child is in the daemon's own
process group and dies with it.

Non-goal: surviving a daemon restart. The agent is a child of the daemon, full
stop — the detached-runner design is a separate milestone. Non-goal: any agent
other than Claude Code.

Depends on: #133

New crate `maestro-acp`, wrapping the `agent-client-protocol` crate (crates.io, maintained by Zed) in the **client** role. The daemon is the client; the adapter is the server. Spawning a session with `view: Structured` starts `claude-code-acp` as a child process with stdio pipes, in the session's `cwd`, with the session's env. The adapter is resolved on `PATH`; if it is missing the session is created in a failed state carrying an actionable message naming the install command, rather than a silently dead session. Document the install in `docs/INSTALL.md`. **The handshake declares almost nothing.** `initialize` reports `fs.readTextFile`, `fs.writeTextFile` and `terminal` as **false**, so the adapter uses Claude Code's own Read / Write / Bash instead of asking the daemon to act on its behalf. That is what already happens in the terminal view, and it keeps the daemon out of the business of enforcing a filesystem boundary. `session/request_permission` is the one client method that gets a real implementation, in #7. Then `session/new` with the session's cwd, and hold the returned ACP session id in the sidecar so a later respawn can `session/load` it. Kill and daemon shutdown both terminate the child: `DELETE /api/sessions/:id` sends `session/cancel`, waits briefly, then SIGTERMs. The child is in the daemon's own process group and dies with it. Non-goal: surviving a daemon restart. The agent is a child of the daemon, full stop — the detached-runner design is a separate milestone. Non-goal: any agent other than Claude Code. Depends on: #133

naps62-yolo added this to the Structured view milestone 2026-09-03 10:36:12 +01:00

naps62-yolo added the difficulty/hard area/daemon type/feat labels 2026-09-03 10:36:12 +01:00

naps62-yolo referenced this issue

2026-09-03 10:36:15 +01:00

Persist ACP notifications to a per-session event log #135

naps62-yolo added a new dependency 2026-09-03 10:36:28 +01:00

#133 Add `SessionView` to the protocol and sidecar

naps62-yolo added a new dependency 2026-09-03 10:36:29 +01:00

#135 Persist ACP notifications to a per-session event log