The runtime already framed JSON-RPC initialize traffic over stdio, so this extends the same transport with typed helpers for tools/list, tools/call, resources/list, and resources/read plus fake-server tests that exercise real request/response roundtrips.
Constraint: Must build on the existing stdio JSON-RPC framing rather than introducing a separate MCP client layer
Rejected: Leave method payloads as untyped serde_json::Value blobs | weakens call sites and test assertions
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep new MCP stdio methods aligned with upstream MCP camelCase field names when adding more request/response types
Tested: cargo fmt --manifest-path rust/Cargo.toml --all; cargo clippy --manifest-path rust/Cargo.toml -p runtime --all-targets -- -D warnings; cargo test --manifest-path rust/Cargo.toml -p runtime
Not-tested: Live integration against external MCP servers
The runtime already knew how to spawn stdio MCP processes, but it still
needed transport primitives for framed JSON-RPC exchange. This change adds
minimal request/response types, line and frame helpers on the stdio wrapper,
and an initialize roundtrip helper so later MCP client slices can build on a
real transport foundation instead of raw byte plumbing.
Constraint: Keep the slice small and limited to stdio transport foundations
Constraint: Must verify framed request write and typed response parsing with a fake MCP process
Rejected: Introduce a broader MCP session layer now | would expand the slice beyond transport framing
Rejected: Leave JSON-RPC as untyped serde_json::Value only | weakens initialize roundtrip guarantees
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Preserve the camelCase MCP initialize field mapping when layering richer protocol support on top
Tested: cargo fmt --all --manifest-path rust/Cargo.toml
Tested: cargo clippy -p runtime --all-targets --manifest-path rust/Cargo.toml -- -D warnings
Tested: cargo test -p runtime --manifest-path rust/Cargo.toml
Not-tested: Integration against a real external MCP server process
The dirty stdio slice had two real regressions in its new JSON-RPC test coverage: the embedded Python helper was written with broken string literals, and direct execution of the freshly written helper could fail with ETXTBSY on Linux. The repair keeps scope inside mcp_stdio.rs by fixing the helper strings and invoking the JSON-RPC helper through python3 while leaving the existing stdio process behavior unchanged.
Constraint: Keep the repair limited to rust/crates/runtime/src/mcp_stdio.rs
Constraint: Must satisfy fmt, clippy -D warnings, and runtime tests before shipping
Rejected: Revert the entire JSON-RPC stdio coverage addition | unnecessary once the helper/test defects were isolated
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep ephemeral stdio test helpers portable and avoid directly execing freshly written scripts when an interpreter invocation is sufficient
Tested: cargo fmt --all; cargo clippy -p runtime --all-targets -- -D warnings; cargo test -p runtime
Not-tested: Cross-platform behavior outside the current Linux runtime
Add a minimal runtime stdio MCP launcher that spawns configured server processes with piped stdin/stdout, applies transport env, and exposes async write/read/terminate/wait helpers for future JSON-RPC integration.
The wrapper stays intentionally small: it does not yet implement protocol framing or connection lifecycle management, but it is real process orchestration rather than placeholder scaffolding. Tests use a temporary executable script to prove env propagation and bidirectional stdio round-tripping.
Constraint: Keep the slice minimal and testable while using the real tokio process surface
Constraint: Runtime verification must pass cleanly under fmt, clippy, and tests
Rejected: Add full JSON-RPC framing and session orchestration in the same commit | too much scope for a clean launcher slice
Rejected: Fake the process wrapper behind mocks only | would not validate spawning, env injection, or stdio wiring
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Layer future MCP protocol framing on top of McpStdioProcess rather than bypassing it with ad hoc process management
Tested: cargo fmt --all; cargo clippy -p runtime --all-targets -- -D warnings; cargo test -p runtime
Not-tested: live third-party MCP servers; long-running process supervision; stderr capture policy
Add a minimal runtime MCP client bootstrap layer that turns typed MCP configs into concrete transport targets with normalized names, tool prefixes, signatures, and auth requirements.
This is intentionally scaffolding rather than a live connection manager: it creates the real data model the runtime will need to launch stdio, remote, websocket, sdk, and claude.ai proxy clients without prematurely coupling the code to any specific async transport implementation.
Constraint: Keep the slice real and minimal without adding connection lifecycle complexity yet
Constraint: Runtime verification must stay green under fmt, clippy, and tests
Rejected: Implement live connection/session orchestration in the same commit | too much surface area for a clean foundational slice
Rejected: Leave bootstrap shaping implicit in future transport code | would duplicate transport mapping and weaken testability
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Build future MCP launch/execution code by consuming McpClientBootstrap/McpClientTransport rather than re-parsing config enums ad hoc
Tested: cargo fmt --all; cargo clippy -p runtime --all-targets -- -D warnings; cargo test -p runtime
Not-tested: live MCP server processes; remote stream handshakes; tool/resource enumeration against real servers
Add runtime MCP helpers for name normalization, tool naming, CCR proxy URL unwrapping, config signatures, and stable scope-independent config hashing.
This is the fastest clean parity-unblocking MCP slice because it creates real reusable behavior needed by future client/transport work without forcing a transport boundary prematurely. The helpers mirror key upstream semantics around normalized tool names and dedup/config-change detection.
Constraint: Must land a real MCP foundation without pulling transport management into the same commit
Constraint: Runtime verification must pass with fmt, clippy, and tests
Rejected: Start with transport/client scaffolding first | would need more design surface and more unverified edges
Rejected: Leave normalization/signature logic implicit in later client code | would duplicate behavior and complicate testing
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Reuse these helpers for future MCP tool naming, dedup, and reconnect/change-detection work instead of re-encoding the rules ad hoc
Tested: cargo fmt --all; cargo clippy -p runtime --all-targets -- -D warnings; cargo test -p runtime
Not-tested: live MCP transport connections; plugin reload integration; full connector dedup flows
Add minimal runtime-side remote session and upstream proxy primitives that model enablement, session identity, token loading, websocket endpoint derivation, and subprocess proxy environment shaping.
This intentionally stops short of implementing the relay or CA download path. The goal is to land real request/env foundations that future remote integration work can build on while preserving the fail-open behavior of the upstream implementation.
Constraint: Must keep the slice minimal and real without pulling in relay networking yet
Constraint: Verification must pass with runtime fmt, clippy, and tests
Rejected: Implement full upstream CONNECT relay now | too large for the current bounded slice
Rejected: Hide proxy state behind untyped env maps only | would make later integration and testing brittle
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep remote bootstrap logic fail-open; do not make proxy setup a hard dependency for normal runtime execution
Tested: cargo fmt --all; cargo clippy -p runtime --all-targets -- -D warnings; cargo test -p runtime
Not-tested: live CCR session behavior; relay startup; CA bundle download and trust installation
Add runtime OAuth primitives for PKCE generation, authorization URL building, token exchange request shaping, and refresh request shaping. Wire the API client to a real auth-source abstraction so future OAuth tokens can flow into Anthropic requests without bespoke header code.
This keeps the slice bounded to foundations: no browser flow, callback listener, or token persistence. The API client still behaves compatibly for current API-key users while gaining explicit bearer-token and combined auth modeling.
Constraint: Must keep the slice minimal and real while preserving current API client behavior
Constraint: Repo verification requires fmt, tests, and clippy to pass cleanly
Rejected: Implement full OAuth browser/listener flow now | too broad for the current parity-unblocking slice
Rejected: Keep auth handling as ad hoc env reads only | blocks reuse by future OAuth integration paths
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Extend OAuth behavior by composing these request/auth primitives before adding session or storage orchestration
Tested: cargo fmt --all; cargo clippy -p runtime -p api --all-targets -- -D warnings; cargo test -p runtime; cargo test -p api --tests
Not-tested: live OAuth token exchange; callback listener flow; workspace-wide tests outside runtime/api
Add typed runtime-facing MCP and OAuth configuration models on top of the existing merged settings loader so later parity work can consume validated structures instead of ad hoc JSON traversal.
This keeps the first slice bounded to parsing, precedence, exports, and tests. While validating the slice under the repo's required clippy gate, I also fixed a handful of pre-existing clippy failures in runtime file operations so the requested verification command can pass for this commit.
Constraint: Must keep scope to parity-unblocking primitives, not full MCP or OAuth flow execution
Constraint: cargo clippy --all-targets is a required verification gate for this repo
Rejected: Add a new integrations crate first | too much boundary churn for the first landing slice
Rejected: Leave existing clippy failures untouched | would block the required verification command for this commit
Confidence: medium
Scope-risk: moderate
Reversibility: clean
Directive: Keep future MCP/OAuth additions layered on these typed config surfaces before introducing transport orchestration
Tested: cargo fmt --all; cargo test -p runtime; cargo clippy -p runtime --all-targets -- -D warnings
Not-tested: workspace-wide clippy/test beyond the runtime crate; live MCP or OAuth network flows
Trace the local Claude Code TS request path and align the Rust client with its
non-OAuth direct-request behavior. The Rust client now resolves the message base
URL from ANTHROPIC_BASE_URL, uses ANTHROPIC_API_KEY for x-api-key, and sends
ANTHROPIC_AUTH_TOKEN as a Bearer Authorization header when present.
Constraint: Must match the local Claude Code source request/auth split, not inferred behavior
Rejected: Treat ANTHROPIC_AUTH_TOKEN as the x-api-key source | diverges from local TS client path
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep direct /v1/messages auth handling aligned with src/services/api/client.ts and src/utils/auth.ts when changing env precedence
Tested: cargo test -p api; cargo run -p rusty-claude-cli -- prompt "say hello"
Not-tested: Non-default proxy transport features beyond ANTHROPIC_BASE_URL override
Wire the CLI to the Anthropic client, runtime conversation loop, and MVP in-tree tool executor so prompt mode and the default REPL both execute real turns instead of scaffold-only commands.
Constraint: Proxy auth uses ANTHROPIC_AUTH_TOKEN as the primary x-api-key source and may stream extra usage fields
Constraint: Must preserve existing scaffold commands while enabling real prompt and REPL flows
Rejected: Keep prompt mode on the old scaffold path | does not satisfy end-to-end CLI requirement
Rejected: Depend solely on raw SSE message_stop from proxy | proxy/event differences required tolerant parsing plus fallback handling
Confidence: medium
Scope-risk: moderate
Reversibility: clean
Directive: Keep prompt mode tool-free unless the one-shot path is explicitly expanded and reverified against the proxy
Tested: cargo test -p api; cargo test -p tools; cargo test -p runtime; cargo test -p rusty-claude-cli; cargo build; cargo run -p rusty-claude-cli -- prompt "say hello"; printf '/quit\n' | cargo run -p rusty-claude-cli --
Not-tested: Full interactive tool_use roundtrip against the proxy in REPL mode
The old tracked TypeScript snapshot has been removed from the repository history and the root directory is now a Python porting workspace. README and tests now describe and verify the Python-first layout instead of treating the exposed snapshot as the active source tree.
A local archive can still exist outside Git, but the tracked repository now presents only the Python porting surface, related essay context, and OmX workflow artifacts.
Constraint: Tracked history should collapse to a single commit while excluding the archived snapshot from Git
Rejected: Keep the exposed TypeScript tree in tracked history under an archive path | user explicitly wanted only the Python porting repo state in Git
Confidence: medium
Scope-risk: broad
Reversibility: messy
Directive: Keep future tracked additions focused on the Python port itself; do not reintroduce the exposed snapshot into Git history
Tested: python3 -m unittest discover -s tests -v; python3 -m src.main summary; git diff --check
Not-tested: Behavioral parity with the original TypeScript system beyond the current Python workspace surface
