OpenClaw Claude CLI Proxy: Subprocess Wrapping

The same question came up in three separate meetings at a small law firm: we already pay for these seats, so why can the intake queue not just call them? It is a fair question, and the invoice does not answer it. The subscription terms do, and here the answer is no. Wrapping a paid Claude Code seat as an endpoint for other software is not a use Anthropic permits, and the account can be closed over it. That is why what follows is written as a study, with the risk section placed ahead of the architecture on purpose. Read it as the question to settle before you point ai automation tools at a seat that was sold for one person.

The short version:

• The honest framing first. This is an architecture study of wrapping claude -p as a local OpenAI-compatible endpoint. It is not a usage Anthropic authorizes. Account-ban risk is real, it is not ToS-compliant, and you should not run it against an account whose access you can not afford to lose
• The pattern is the cleanest fingerprint of any proxy I tested — every request comes from a real CLI subprocess, not a re-implementation of one. From the server side, it looks like a person typing
• Five layers — types, infra, server, bridge, cli — each owning one job, each testable on its own. The first version was one big Express app and it did not survive the second feature
• Multimodal routing splits text requests to the CLI and image/audio/video requests to Gemini. Per-request budget caps and a priority queue keep one bad prompt from torching the day's quota
• Read the risk section below before anything else. If after reading it you decide this is not for you, that is the right call

⚠️ Risk notice — read first

The pattern described in this article is not authorized by Anthropic's Terms of Service. The ToS does not grant permission to wrap a Claude Code subscription as an API endpoint and serve it to other clients. Three risks follow:

1. Account risk — Anthropic can suspend or ban the underlying account at any time, with no advance notice and no obligation to refund
2. Long-term viability is unknown — the CLI's output format and flags can change in any version update, which would break the wrapper silently
3. No official support — when something goes wrong, Anthropic's support channel will not help with this usage

Treat this as a technical study, not a recommendation. I am writing it because the architecture itself is interesting and worth understanding even if you never run it. If you can not afford to lose access to your Claude account, do not run this against it.

Current OpenClaw note, checked against official docs at time of writing: OpenClaw now documents Claude CLI reuse through agents.defaults.agentRuntime.id: "claude-cli", Claude Code through ACP (/acp spawn claude --bind here), and OpenCode provider routes (opencode/... or opencode-go/...). Those official paths should be evaluated before any subscription proxy.

I spent about a month studying every Claude proxy pattern I could find on GitHub. There are roughly three families of approaches. None of them are clean.

The first family wraps OAuth tokens. You log in with your Anthropic credentials, intercept the bearer token, and replay it from your own server. The fingerprint is wrong — the access pattern from an always-on server does not match what an interactive user would generate.

The second family wraps web cookies. You log into the chat UI, scrape the session cookies, and replay them from your server. The fingerprint is also wrong — the cookies come with browser-shaped headers a CLI never sends, so a session built from cookies emits an inconsistent signature.

The third family wraps the SDK. You build your proxy on top of the public Anthropic SDK and re-issue requests from there. The fingerprint is closer to clean but still off — the SDK's request shape is subtly different from the CLI's, and over time those subtleties stack into a recognizable pattern.

After exhausting the three families, I landed on the dumbest option: don't wrap anything. Just shell out to claude -p and let the actual CLI make the actual request. Every request that hits Anthropic's servers comes from the genuine subprocess, with the genuine binary, sending the genuine headers. From the server side, it looks like a person typing.

That decision became the foundation of the architecture I want to walk through here. Not because I'm recommending you run it — see the risk notice above — but because the design choices are interesting on their own and worth studying.

Who Is This For

• You're researching Claude proxy patterns and you've already met the OAuth, cookie, and SDK families
• You want to understand the architecture, not necessarily run it — the design lessons transfer
• You're already running OpenClaw and you've thought about how a proxy layer would fit into the agent stack
• You've read the risk section above and you're OK proceeding as a study, not a deployment guide

If you've never deployed OpenClaw before, the OpenClaw multi-agent guide is the right warm-up. If you want a production path for agent reasoning, start with the official OpenClaw routes: direct Anthropic API, Claude CLI backend, ACP Claude Code sessions, or OpenCode provider onboarding. The custom Bridge article is useful only when you need a queue/approval/reporting layer beyond those official surfaces.

If you are comparing proxy shapes, pair this with the OpenClaw Claude SDK proxy study. CLI wrapping optimizes fingerprint similarity; SDK wrapping optimizes structured tool-use.

Why CLI-Subprocess Beats the Alternatives on Fingerprint

The whole architectural payoff hinges on one observation: every request from this proxy is the literal output of claude -p running as a subprocess. Not a reconstruction of what the CLI would emit. Not an SDK call dressed up to look CLI-shaped. The CLI itself.

That gives you several properties for free:

The cost is that you give up control over things you'd want to customize — there's a roughly 5,000-token system prompt that the CLI injects on every request and you can't strip it out, function calling has to be reconstructed via prompt injection because the CLI's pipe mode doesn't expose the native tool API, and streaming has to be simulated because the CLI emits whole chunks rather than per-token deltas.

The trade-off, in one line: the CLI gives you the cleanest fingerprint at the price of giving up fine-grained control. For an agent that mostly does text reasoning, that's the right trade. For a system that needs precise function-calling semantics, it isn't — and the SDK-based pattern is what you should reach for instead.

Two Patterns, One Toolkit

The picture is incomplete without naming the SDK-based companion. The same toolkit that includes this CLI proxy also includes an SDK-based proxy that runs alongside it. They serve different needs:

In a lab or custom proxy deployment they can run side by side and the upstream client can pick which one to use based on the workload. The CLI proxy handles the "this is supposed to look human" requests; the SDK proxy handles the "I need exact tool semantics" requests. Different fingerprints, different strengths, one custom infrastructure.

The Five-Layer Architecture

The first version of this proxy was one Express app with all the logic in the request handler. It worked. It also became unmaintainable by feature three. Five layers fixed it.

The first two layers are the workhorses of the design. The CLI layer talks to Claude (spawn the subprocess, isolate it in a sandbox, parse the output). The bridge layer translates between two protocols (OpenAI in, CLI prompt out, then CLI events in, OpenAI response out).

The plain-English version: think of the system as a translation agency. The CLI layer is the desk that talks to the foreign-language clients. The bridge layer is the translator who renders foreign requests into the local language. The server layer is the front office that accepts incoming work. The infra layer is the back-office that handles queueing, accounting, and monitoring. The types layer is the dictionary every other layer pulls from.

A Request, End to End

Watch a single request travel the architecture and the design choices stop being abstract.

1. Client sends an OpenAI-format request → Express router receives it
2. Bridge flattens the multi-turn message array into one CLI-friendly prompt string
3. Bridge appends tool definitions to the prompt if the request includes any
4. CLI spawns a real claude -p subprocess in an isolated sandbox directory
5. CLI parses the line-delimited JSON event stream coming back from the subprocess
6. CLI extracts any tool-call invocations the model embedded in its text reply
7. Bridge repackages the result into OpenAI response format
8. Server streams the response back to the client

If the request has any image content, the whole thing detours: it never touches the CLI, it goes straight to the Gemini API instead. Pure text protects the fingerprint; multimodal preserves the feature.

Pause here. You've now seen the architecture and the data flow. The next two sections drill into the layers that earn the architecture its keep — the bridge protocol translation and the CLI subprocess management.

Module-Level Design Decisions

There are six modules that hold most of the load. Each one solved a problem I hit in production; each one is worth understanding even if you never write the code.

`executor.ts` — Dual-Mode Fingerprint Strategy

This is the soul of the project. It decides the exact arguments passed to claude -p, and that decision drives everything visible to Anthropic.

The strategy is dual-mode. With no tool calls, the proxy passes only the prompt and nothing else — the exact invocation a person typing claude -p "your prompt" would emit. With tool calls, the proxy adds two flags: one to inject the tool definitions into the prompt, one to disable the CLI's built-in tools so they don't compete with the user-supplied ones. Two extra flags is still close to a normal CLI user; it's the smallest possible deviation.

The principle in one line: when there's nothing custom to add, add nothing. The special-case branch becomes a no-op rather than a different code path. That's both architecturally cleaner and more fingerprint-faithful.

The other thing this module owns is sandbox isolation. Each request creates a fresh temp directory as the subprocess's working directory; when the request finishes, the directory is deleted. Without this, two concurrent requests could see each other's files. I learned this the hard way the first time two requests' artifacts cross-contaminated and I spent an afternoon figuring out why one user's response had pieces of another user's draft in it.

`parser.ts` — NDJSON with Buffering

The CLI emits newline-delimited JSON, one event per line. In theory, that's easy to parse. In practice, two real-world artifacts make it hard:

• Packet aggregation: Sometimes one TCP frame contains multiple JSON lines glued together
• Packet fragmentation: Sometimes one JSON object spans two TCP frames

The parser handles both with a buffer: append every chunk, split on newlines, parse each complete line, hold the trailing fragment for the next chunk. The events you actually care about:

`messages.ts` — Bracket-Bracket Role Markers

OpenAI format has four roles — system, user, assistant, tool. The CLI accepts one prompt string. So the bridge has to flatten the multi-turn conversation into a single string, with role markers Claude can read.

I tried XML tags first. Disaster. Claude is good at pattern-matching its inputs and reflecting them in its outputs — feed it XML-tagged inputs and it starts emitting XML-tagged outputs, which then need their own parsing layer downstream.

Bracket markers ([user], [assistant], [system]) work better because Claude doesn't reflect them. They're foreign enough to the prose flow that they stay in the input layer. The right marker is one Claude sees but does not imitate.

`tools.ts` — Function Calling via Prompt Injection

The CLI's pipe mode doesn't expose Anthropic's native tool-use API. To get function calling, the bridge has to fake it: take the OpenAI-format tool definitions, render them into a Markdown spec, append the spec to the system instructions, and teach the model to emit tool calls in a specific text format the parser can recognize.

Reliability is around 95% on Opus and Sonnet. Not 100% — that's the cost of faking it. The other five percent are cases where the model paraphrases the tool-call format in a way the parser misses, and the request silently degrades into a plain text response. For workflows that absolutely need 100% tool reliability, the SDK proxy is the right tool.

The implementation rule: the clearer the tool descriptions, the higher the format-adherence rate. Vague descriptions give the model permission to "improvise" the format. Spell out the schema; reliability follows.

`response.ts` — Dual-Format Tool-Call Extraction

Once Claude has emitted a tool call in text form, the response parser pulls it out. Defensive design choice: support two formats in parallel — the format we taught it, and the XML format Claude sometimes invents on its own. Fighting the model is more expensive than supporting both.

`routes.ts` — Simulated Streaming

The CLI emits whole text chunks; OpenAI clients expect per-token deltas. The router fakes incremental delivery by chunking the chunks: split on punctuation and newlines, emit each piece as a delta, send the final stop event. Less precise than true token-by-token streaming, but the UX is close enough that no human reader notices.

Four Design Decisions That Earn Their Keep

Beyond the layered architecture, four operational choices are what keep the proxy stable in real use.

Opus auto-degrade

Claude Opus saturates fast at peak hours. When the CLI returns a 503 specifically because Opus is overloaded, the proxy automatically retries with Sonnet rather than failing the whole request. The client sees the model that actually answered in the response metadata, so there's no silent substitution. A degraded answer beats no answer for almost every workload.

The mental model: like walking into your favorite restaurant, finding it full, and the host walking you next door to a place that's nearly as good. Better than going home hungry.

Per-request budget cap

The CLI ships with native tool access (Bash, Read, Edit) that the proxy does not strip. In principle, the model could decide to spin in a tool loop and burn the day's quota in one request. The cap aborts the request the moment cumulative token spend crosses a configurable threshold (default: five dollars). One bad prompt costs a single request, not the whole day.

Priority queue for heartbeat traffic

In an OpenClaw deployment, agents can send heartbeat checks on the configured cadence. Those checks do not need full Opus reasoning. The proxy detects heartbeat-pattern requests and:

• Demotes them to a low-priority lane
• Injects a "reply tersely" instruction
• Lets the response shrink from ~200 tokens to ~20

That keeps the high-priority lane open for real user-driven requests, and it compounds into noticeable quota savings over a day. Heartbeat traffic is necessary; expensive heartbeat traffic is not.

Watchdog with bounded retries

A startup script wraps the whole proxy in a watchdog. If the proxy dies, the watchdog restarts it. If the proxy dies more than five times in five minutes, the watchdog stops trying — that pattern almost always means the CLI is broken (logged-out, version-mismatched, missing) and infinite retry just wastes resources. Bounded retry is what separates a watchdog from an infinite loop.

Deployment in Practice

The deployment story is intentionally Claude-Code-driven: read the source pack, point Claude Code at it, and let it walk through the install. The human only confirms the environment-specific details.

me: "Read /your-path/source/CLAUDE.md and deploy the Claude CLI Proxy."
cc: (walks through the install, asks for env vars, runs the health check)
me: "Send a curl to the local endpoint to verify it works."
cc: (runs the curl, shows the response, confirms the wrapper is up)

The minimal environment required:

Configuration is environment-variable driven, with sensible defaults:

The one operational rule: never test this proxy from inside Claude Code itself. Claude Code and the proxy share the same Max subscription's concurrency budget, so testing from inside the CLI deadlocks against the subprocess the CLI itself is hosting. Test from a separate terminal.

Honest Cost-and-Risk Accounting

I need to come back to the risk picture, because no amount of architecture cleanliness changes the underlying ToS situation.

If any of those four costs would meaningfully damage you — financially, operationally, professionally — don't run this. The architecture is interesting; the risk is not.

The case where it might be reasonable: a personal account, used for personal experimentation, where losing access would be inconvenient but not catastrophic. The case where it almost certainly isn't reasonable: any production system, any business-critical workflow, any account whose suspension would impact other people who depend on you.

The honest version: I'm not running this against my main account. I built it to study the pattern. The architecture lessons transfer to other proxy designs that are on more solid ToS ground; that's the value, not the deployment.

Pitfalls You Can Skip

Five places I lost time you don't have to.

Pitfall 1: Forgetting sandbox isolation. Two concurrent requests' artifacts cross-contaminated; debugging took the whole afternoon. Per-request temp directory + cleanup-on-exit fixes it cleanly.

Pitfall 2: XML role markers. Claude reflected the XML in its outputs, broke downstream parsing. Bracket markers don't get reflected.

Pitfall 3: Fighting Claude's tool-call format. Two formats in parallel beat trying to discipline the model into one format. Engineering > pedagogy when the model is involved.

Pitfall 4: Unbounded watchdog retry. Five-in-five-minutes is the right cap. Without it, a misconfigured CLI retries forever and the failure surfaces as "server is up but every request fails" rather than a clean alarm.

Pitfall 5: Testing from inside Claude Code. The CLI and the proxy share the same subscription's concurrency budget. Always test from a separate terminal.

Where the Proxy Sits in OpenClaw

The proxy is one path agents can use to reason. It's not the only path. The full picture:

For current OpenClaw production, start with official provider/runtime paths. The CLI proxy is for studying; custom Bridge is optional infrastructure when you deliberately need extra queue, approval, and reporting behavior.

Key Takeaways

• Honest framing first. This is an architecture study, not a deployment recommendation. The ToS posture matters more than the cleverness
• CLI-subprocess wins on fingerprint. Every request comes from the actual binary; nothing to fake or reconstruct
• Five layers earn their keep. Types, infra, server, bridge, cli. Each one job; each testable in isolation
• Dual-mode fingerprint = add nothing when there's nothing custom to add. The special-case branch becomes a no-op
• Multimodal routing splits text and image cleanly. Text protects fingerprint; Gemini preserves the feature
• Operational guardrails matter more than architectural elegance. Budget cap, priority queue, watchdog, bounded retry — these are what keep it stable in real use
• For production OpenClaw, use official paths first. Direct Anthropic API, Claude CLI backend, ACP Claude Code, and OpenCode provider routes now cover the mainstream cases

Ready-to-Use Prompt: Architect a Five-Layer CLI-Subprocess Proxy (Risk-First)

What this does: Forces the account-ban/ToS risk decision first, then lays out the five decoupled layers (types, infra, server, bridge, cli), designs the CLI-subprocess bridge for a clean fingerprint, sets multimodal routing, adds per-request budget caps and a priority queue, and validates layer isolation — as an architecture study, not an authorized usage.
Based on: OpenClaw Claude CLI Proxy: Subprocess Wrapping — https://aiworkflowpro.com/openclaw-claude-subscription-proxy/
Time to run: ~5 minutes

Copy this prompt into Claude Code, ChatGPT, or any AI assistant:

ROLE: You are a proxy-architecture reviewer. Your job: assess a plan to wrap a CLI as a local OpenAI-compatible endpoint across five decoupled layers, with multimodal routing and budget guards — while forcing the honest account-ban/ToS risk to the front of every decision.

CONTEXT — FIVE-LAYER CLI-SUBPROCESS PROXY:
The pattern wraps a CLI (e.g., claude -p) as a local OpenAI-compatible endpoint by spawning a real CLI subprocess per request — the cleanest fingerprint of any proxy (each request looks like a person typing, not a re-implementation). A maintainable version is five layers, each owning one job and testable alone: types, infra, server, bridge, cli (a single Express app does not survive the second feature). Multimodal routing splits text to the CLI and image/audio/video to a multimodal provider; per-request budget caps and a priority queue keep one bad prompt from torching the day's quota. Honest framing: this is an architecture study, not an Anthropic-authorized usage — account-ban risk is real, it is not ToS-compliant, and you must not run it against an account you cannot afford to lose.

INPUTS (fill in before running):
- PROXY_GOAL: YOUR_OBJECTIVE_HERE (why you want the proxy — local OpenAI-compat endpoint for tools, cost, research)
- TARGET_CLI: YOUR_CLI_HERE (the CLI being wrapped)
- MULTIMODAL_NEED: YOUR_ANSWER_HERE (do requests include image/audio/video? yes/no)
- ACCOUNT_RISK_TOLERANCE: YOUR_STANCE_HERE (can you afford to lose the account? yes/no)

METHOD — 6 STEPS:

Step 1 — Force the risk decision first
Before any architecture: confirm ACCOUNT_RISK_TOLERANCE. If "no, cannot afford to lose the account," stop — this pattern is not ToS-compliant and carries real ban risk; do not proceed against that account. Architecture comes only after the user accepts the risk knowingly.

Step 2 — Lay the five layers
Define the layers, each one job, each testable alone: types (shared schemas) · infra (process/runtime) · server (the OpenAI-compatible HTTP surface) · bridge (request↔CLI translation) · cli (the subprocess wrapper). No layer does another's job — the monolith fails at the second feature.

Step 3 — Design the CLI-subprocess bridge
The bridge spawns a real TARGET_CLI subprocess per request (not a re-implementation) — this is what gives the clean fingerprint. Define how stdin/stdout/exit codes map to the OpenAI request/response, and how errors surface.

Step 4 — Set multimodal routing
If MULTIMODAL_NEED = yes, route text → TARGET_CLI and image/audio/video → a multimodal provider (e.g., Gemini). Single-modality CLI calls must not break on multimodal input — route before the bridge.

Step 5 — Set budget caps and priority queue
Add per-request budget caps and a priority queue so one runaway prompt cannot consume the day's quota. Define the cap (tokens/time), the priority levels, and the reject behavior when a request exceeds budget.

Step 6 — Validate layer isolation and risk
Check: (1) is each layer testable alone? (2) does the bridge use a real subprocess (clean fingerprint)? (3) does multimodal routing split correctly? (4) do budget caps protect the quota? (5) is the ToS/ban-risk disclaimer present at the entry point? Fail any → fix.

RULES:
- The ToS/ban-risk decision comes before architecture — never run this against an account you cannot afford to lose.
- Five layers, each one job and independently testable — no monolith, no cross-layer leakage.
- The bridge spawns a real CLI subprocess per request; a re-implementation loses the clean fingerprint.
- Per-request budget caps + priority queue are mandatory — one bad prompt must not torch the quota.

OUTPUT FORMAT:
Output six sections:
1. **Risk decision** — ACCOUNT_RISK_TOLERANCE + the go/stop verdict (stop if the account cannot be lost).
2. **Five layers** — markdown table with columns: Layer | Owns | Testable alone? (Y/N).
3. **CLI-subprocess bridge** — the subprocess spawn + stdin/stdout/exit mapping.
4. **Multimodal routing** — text vs image/audio/video split (or "single-modality" if MULTIMODAL_NEED = no).
5. **Budget + priority** — the per-request cap, priority levels, reject behavior.
6. **Validation** — markdown table with columns: Check | Pass? (Y/N), with the ToS-disclaimer-present check included.

Save as @templates/openclaw-claude-subscription-proxy.md and run only as an architecture study — and re-read the risk section before any deployment against a real account.

Frequently Asked Questions

Does this proxy approach violate Anthropic's Terms of Service?

It is not a usage that Anthropic has explicitly authorized. The Terms of Service do not grant blanket permission to wrap a Claude Code subscription as an API endpoint and serve it to other clients. That means three concrete risks apply to anyone who runs this: Anthropic can ban the underlying account at any time and is not obligated to give notice; the CLI's output format can change in any update and break the wrapper without warning; there is no official support channel for problems caused by this pattern. Treat this article as an architecture study, not a recommendation to run anything in production. If you can not afford to lose access to your Claude account, do not run this against it.

Why is this approach "cleaner" from a fingerprint perspective than the alternatives?

Because every request to Anthropic's servers is made by the actual claude -p subprocess — the same binary, the same environment, the same headers a normal user would emit. OAuth-token-based proxies present a different access pattern than a logged-in CLI; web-cookie-based proxies emit headers a CLI never would; SDK-based proxies often miss subtle headers the CLI sends by default. The CLI subprocess approach inherits the entire CLI's request shape for free, which is the closest you can get to "this is just a person typing into the terminal" from the server's perspective. Whether that is enough to evade detection long-term is unknowable; what is true is that it is the most fingerprint-faithful of the patterns publicly available.

Why five layers? Couldn't this be a single Express app?

It could, and an early version was. Three failure modes pushed it to five layers. First, the protocol-translation logic (OpenAI-format messages to CLI prompt strings) kept growing and contaminating the request handler; pulling it into a bridge layer let each side be tested independently. Second, the subprocess management (sandbox dirs, timeout, sandbox cleanup) got complex enough that it needed its own home — that became the cli layer. Third, the cross-cutting concerns (queue, metrics, log rotation, error handling) were getting copy-pasted into every code path; consolidating them into an infra layer ended that. The five layers are: types (data shapes), infra (cross-cutting), server (HTTP), bridge (protocol translation), cli (subprocess execution). Each one job; each testable in isolation.

What does "dual-mode fingerprint" actually mean in practice?

It means the proxy invokes claude -p with the smallest possible argument set in each scenario. When the request has no tool-use, it passes only the prompt and nothing else — exactly what a person typing "claude -p" in their terminal would emit. When the request includes tools, it has to pass two extra flags (one to inject tool definitions, one to disable the CLI's built-in tools), which slightly enlarges the fingerprint but still keeps it close to a normal CLI user. The principle is "when there is nothing custom to add, add nothing" — the special-case branch becomes a no-op rather than a different code path, which is both cleaner and more fingerprint-faithful.

How does multimodal routing work and why isn't it just "use the CLI for everything"?

The CLI's pipe mode only accepts plain text — it cannot receive images, audio, or video. So the proxy detects multimodal content in the incoming request and, when found, routes the entire request to the Gemini API instead of the CLI. Pure text requests stay on the CLI path (zero marginal cost, covered by the subscription); multimodal requests go to Gemini (pay-per-use, optional). This split keeps the fingerprint clean for the bulk of traffic while still supporting the rare image-attached request. If you do not need multimodal at all, leave the Gemini API key unset and the proxy refuses multimodal requests cleanly instead of breaking.

What's the per-request budget cap protecting against?

The proxy preserves the CLI's native tool access — the Bash, Read, and Edit tools that ship with Claude Code — which means in principle Claude can do real work in the sandbox during a single request. A maliciously crafted prompt could cause the model to spin in a tool loop and burn through the subscription's quota in one request. The five-dollar cap aborts the request if the cumulative token spend crosses that line, which keeps a single bad prompt from emptying the bucket. The cap is configurable; five dollars is a safe default for personal use.

Why is there a separate priority queue for heartbeat-style requests?

Because in an OpenClaw deployment, agents can send heartbeat checks on the configured cadence. Those checks do not need full Opus reasoning — a one-line acknowledgment is enough. The proxy detects heartbeat-pattern requests and demotes them to low-priority, freeing concurrency slots for real user-driven requests. This is custom proxy behavior; current OpenClaw heartbeats use the official heartbeat system and quiet acknowledgements use HEARTBEAT_OK.

Version Compatibility

This proxy depends on the Claude Code CLI's output format, which can change in any version update. To minimize surprise breakage:

1. Pin a known-good Claude Code version
2. Before upgrading, manually run claude -p in a terminal and confirm the output is still line-delimited JSON
3. Restart the proxy and run a smoke test
4. If the format changed, update the parser before exposing the proxy to live traffic

Format changes are not Anthropic doing anything wrong — the CLI is allowed to evolve. The fragility is on your side for choosing to depend on its output shape.

What's Next

If you've read this far and you're still curious, the obvious next stops are the companion patterns and the current official alternatives.

• Agent Workflow Complete Guide — full guide to AI agent workflow automation
• The OpenClaw multi-agent guide — context for why agents need a reasoning layer at all
• The OpenClaw Claude SDK proxy study — the companion wrapper with structured tool-use
• The OpenClaw Bridge integration post — the optional custom queue/approval/reporting architecture
• Official OpenClaw model provider docs — current Claude CLI backend, OpenCode provider, and provider/runtime split
• Official OpenClaw ACP agents docs — current Claude Code external-harness path
• The OpenClaw memory system post — what agents remember when they make repeated calls
• The OpenClaw context-resource patterns — how to budget context across an agent fleet
• The OpenClaw channels and security post — the surrounding security model

Read the source if you want. Run it only against an account whose loss you can afford. The architecture is the gift; the deployment is your call.

— Leo