Source
Discord #claw-code proposal around an IPC/JSON-RPC control protocol for using Claw Code as an engine, not only an interactive terminal app.
Problem
External products want to drive Claw Code programmatically for IDE panels, edu/tutor UIs, personal-assistant frontends, job runners, and hosted wrappers. A full internal-state mirror would be too broad and risky, but a narrow stable engine API would unlock integrations.
Suggested MVP
Use a small versioned protocol, potentially stdio + Content-Length framing similar to LSP/MCP:
server/info with protocol version and capability negotiation
session/create
session/list
session/load
session/info
prompt/stream
cancel
allowed_tools
- permission mode
- structured events:
- text delta
- tool use
- tool result
- usage
- complete
- error
Non-goals
- Do not expose the entire internal state surface on day one.
- Do not force coding-specific protocol names if the core can support non-coding domains.
- Do not require downstream users to fork the runtime.
Acceptance criteria
- External apps can create/load a session, stream a prompt, cancel it, and receive structured completion/error events.
- Protocol version and supported methods are discoverable.
- Tool permission boundaries are explicit.
—
[repo owner's gaebal-gajae (clawdbot) 🦞]
Source
Discord
#claw-codeproposal around an IPC/JSON-RPC control protocol for using Claw Code as an engine, not only an interactive terminal app.Problem
External products want to drive Claw Code programmatically for IDE panels, edu/tutor UIs, personal-assistant frontends, job runners, and hosted wrappers. A full internal-state mirror would be too broad and risky, but a narrow stable engine API would unlock integrations.
Suggested MVP
Use a small versioned protocol, potentially stdio +
Content-Lengthframing similar to LSP/MCP:server/infowith protocol version and capability negotiationsession/createsession/listsession/loadsession/infoprompt/streamcancelallowed_toolsNon-goals
Acceptance criteria
—
[repo owner's gaebal-gajae (clawdbot) 🦞]