Conversation
PoC-1 (PR #229) proved the submit half of v2.1.167's --cloud thin client can be redirected to our gateway. Two questions remain before a real cc-app-gateway (codex-app-gateway shape, per-turn fork) can be designed: 1. Subscribe-half wire format — the v2 CCR transport (SSE reads + POST writes, bootstrapped via POST /v1/code/sessions/{id}/bridge) has never been exercised end-to-end against our mock. 2. Backend harness choice — patched `claude --cloud` (PoC-1 binary, harvest frames from telemetry/stdout) vs plain `claude -p --output-format stream-json` (no backend patches, translate stream-json into v2 frames in the gateway). This Phase 0 spec defines a 2-3 day PoC-2: extend the existing mock to expose the v2 endpoints, drive `claude --teleport <sid>` against it to validate the subscribe channel (gate A.1), then drive each backend candidate into the same SSE stream (A.2, A.3) and write a 5-dimension decision matrix (A.4). All artifacts stay under /tmp/cc-cloud-poc/; only this spec + outcome + memory updates land in the repo. Phase 1 (the actual cc-app-gateway) is a separate spec authored after Phase 0 concludes. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
…be-half unreachable) PoC-2 ran 6 A.1 iterations against v2.1.167 `claude --teleport <sid>`. With 4 new mock routes the binary completed every teleport phase through "Session resumed" and rendered the chat TUI — but never opened any live transport against the mock. 30s post-resume gateway idle window; zero tengu_bridge_* / tengu_ccr_* events in telemetry. Per spec §4 A.1 is a hard gate (no A.1 → no A.2/A.3 → no decision matrix). Per spec §6 the binding stuck-point is structural: the subscribe-half data path the spec was designed to exercise doesn't exist in any v2.1.167 CLI mode. --teleport is local-resume (binary hydrates history then hands off to the local REPL); --cloud is fire-and-forget (PoC-1 finding). The bridge:repl renderer code is in the binary, but its call site is reachable only from `claude assistant`, which remains KAIROS-stripped — exactly what memory cc_binary_internals.md recorded from PoC G back in May 2026. This Phase 0 spec was authored on the incorrect premise that --teleport exercises bridge:repl; it does not. What PoC-2 did contribute: the full HTTP request sequence --teleport actually issues to satisfy a "Session resumed" hydrate against a mock backend (9-step list now in cc_binary_internals.md), and the v2 CCR endpoint shapes (bridge handshake, SSE long-poll, worker delivery ack) that are PRESENT in the binary but UNREACHABLE from any CLI mode without 3+ further patches. Phase 1 cc-app-gateway design implications laid out in spec §11; codex-primary stance reinforced, no agent_integration_strategy.md update needed. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on PR #229 (PoC-1: v2.1.167 --cloud redirect verified, 2 patches).
Phase 0 was meant to answer two questions before designing a real
cc-app-gateway: (1) does the subscribe-half wire format work
end-to-end against our mock, (2) which backend harness candidate
(patched --cloud vs
claude -p stream-json) is the right fit.Result: STUCK at A.1 (subscribe-half). 6 iterations later the
mock served everything
claude --teleport <sid>asked for and thebinary printed "Session resumed" with the chat TUI rendered — but
the gateway saw zero requests for 30 seconds after, telemetry showed
zero
tengu_bridge_*events, and the bridge:repl code path wasnever entered.
--teleportis local-resume; it hydrates history thenhands off to the local REPL.
Per spec §4 A.1 is a hard gate, so A.2/A.3 (backend trials) and A.4
(decision matrix) are NOT attempted. The bridge:repl renderer exists
in the binary but its call site is only reachable from
claude assistant, which remains KAIROS-stripped. Memorycc_binary_internals.mdactually said this back in May 2026 (PoC G);this Phase 0 spec was authored on the incorrect premise that
--teleport exercises bridge:repl.
What did get archived:
resumed" against a forged backend (9 steps documented in spec §11
and updated memory).
binary but unreachable from any CLI mode (
/bridge, SSE/events/stream,/worker/.../delivery).Phase 1 cc-app-gateway design is not authored as a follow-up
spec — the structural finding suggests the cheapest viable shape is
not codex-app-gateway-like at all ("reverse direction" option in
§11: extend the existing Dockerfile.claudecode + sandbox topology).
A future spec, if anyone writes one, will start there.
PoC-2 artifacts (extended mock_gateway.py, run_teleport.sh, 7
iteration journals iter-10..iter-16) live under `/tmp/cc-cloud-poc/`
and are deliberately NOT committed.
🤖 Generated with Claude Code