Add Codex App Server example

[andreisavu]

Summary

• Adds a complete example running OpenAI Codex inside a Cloudflare Sandbox with three-layer egress control to minimize data exfiltration risk
• Worker acts as a WebSocket middleman with a composable JSON-RPC handler pipeline (log, enforceModel, enforcePolicy, autoApprove, sandboxSetup, sandboxExec)
• enableInternet = false — blocks all direct outbound connections at the network level
• interceptHttps = true — HTTPS traffic intercepted via Cloudflare CA cert injection, flowing through the same egress handlers as HTTP
• outboundByHost + outbound — application-level allowlist with deny-by-default catch-all:
  • api.openai.com: allowed with API key injection + HTTPS upgrade (container never sees the real key)
  • github.com: allowed with HTTPS upgrade (needed for repo cloning)
  • Everything else: blocked with 403 Forbidden
• Single-file browser client with dark terminal-meets-chat aesthetic, streaming agent messages, tool call grid, and JSON-RPC debug panel
• Includes integration test and egress validation test

What's included

File	Description
src/index.ts	Sandbox subclass (enableInternet=false, interceptHttps=true), egress proxy, WebSocket bridge, sandbox lifecycle
src/rpc.ts	JSON-RPC types + composable handler pipeline
public/index.html	Browser client (session gate, streaming chat, tool grid)
Dockerfile	cloudflare/sandbox:0.8.7 + @openai/codex CLI
test.mjs	E2E smoke test (WebSocket handshake, repo clone, prompt round-trip)
test-egress.mjs	Egress constraint validation (API key injection, allowed/blocked hosts)

Egress security model

Container (enableInternet=false)
│
├─ Raw TCP to non-allowed hosts ──► BLOCKED (network level)
│
├─ HTTP to any host ──► outboundByHost / outbound handlers
│   ├─ api.openai.com ──► inject API key, upgrade to HTTPS ──► OpenAI
│   ├─ github.com ──► upgrade to HTTPS ──► GitHub
│   └─ * (catch-all) ──► 403 Forbidden
│
└─ HTTPS to any host (interceptHttps=true) ──► same handlers as HTTP
    ├─ api.openai.com ──► inject API key ──► OpenAI
    ├─ github.com ──► forward ──► GitHub
    └─ * (catch-all) ──► 403 Forbidden

Test plan

• npm run dev starts locally, WebSocket connects, Codex handshake succeeds
• sandbox/setup clones a repo into /workspace
• Agent responds to prompts with streaming deltas
• Egress: api.openai.com returns 200 with injected API key (HTTP + HTTPS)
• Egress: github.com returns 301 (allowed, HTTP + HTTPS)
• Egress: example.com and httpbin.org return 403 (blocked, HTTP + HTTPS)
• Egress: raw TCP to non-allowed hosts times out (enableInternet=false)
• Egress: DNS resolves but blocked hosts unreachable
• Container never has real API key (OPENAI_API_KEY=proxy-injected)
• wrangler deploy succeeds and production endpoint works
• Git clone via sandbox/setup works with HTTPS interception enabled

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8b78b90

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[andreisavu]

The egress network enforcement here is not as comprehensive and granular as I would like it to be. Seeking some advice on how to improve the configs to ensure that the risk of data exfiltration due to prompt injection is minimized.

I've made some attempts at settings enableInternet to false and unsuccessfully tried to enable the upcoming support for https request interception. Setting enableInternet=false kind of breaks it and the container immediately shutdowns after start.

[scuffi]

The egress network enforcement here is not as comprehensive and granular as I would like it to be. Seeking some advice on how to improve the configs to ensure that the risk of data exfiltration due to prompt injection is minimized.

I've made some attempts at settings enableInternet to false and unsuccessfully tried to enable the upcoming support for https request interception. Setting enableInternet=false kind of breaks it and the container immediately shutdowns after start.

Hey Andrei! Whilst HTTPS is still in development you'll need to pin a specific version of containers which we can remove in future once this is standard in the sandbox-sdk. For now, can you temporarily pin this containers package in your example?

cd examples/codex-app-server
npm i https://pkg.pr.new/cloudflare/containers/@cloudflare/containers@171

Then I've left a little suggestion about how to enable this in the Sandbox, let me know if this works!

[andreisavu]

thanks @scuffi! will try out things locally to see if this gets me closer to what will feel likely a semi-air-gapped environment.

[andreisavu]

Egress testing results — deployed to Cloudflare

Applied @scuffi's recommendations: Sandbox subclass with enableInternet = false + interceptHttps = true, pinned @cloudflare/containers@171, simplified outbound handlers. Deployed and tested against production.

Configuration

export class Sandbox extends BaseSandbox<Env> {
  enableInternet = false;
  interceptHttps = true;
}

Test results (21 probes from inside the container via sandbox/exec)

Probe	Result	Verdict
HTTP api.openai.com (port 80)	200	✅ Allowed — API key injected by proxy
HTTP github.com (port 80)	301	✅ Allowed — passthrough
HTTP example.com (port 80)	403	✅ Blocked by deny-by-default handler
HTTP httpbin.org (port 80)	403	✅ Blocked
HTTPS example.com (port 443)	403	✅ Intercepted and blocked
HTTPS httpbin.org (port 443)	403	✅ Intercepted and blocked
HTTPS api.openai.com (port 443)	200	✅ Intercepted — key injected, works
POST exfil via HTTP	403	✅ Blocked
POST exfil via HTTPS	403	✅ Blocked
Raw TCP portquiz.net:8080 (bash /dev/tcp)	timeout	✅ Blocked by enableInternet=false
Node net.connect portquiz.net:8080	timeout	✅ Blocked
Raw TCP example.com:80 (bash /dev/tcp)	OPEN	⚠️ Connects to egress proxy, gets 403
Raw TCP example.com:443 (bash /dev/tcp)	OPEN	⚠️ Connects to HTTPS proxy, gets 403
Node net.connect example.com:443	CONNECTED then ECONNRESET	⚠️ Same — proxy accepts then resets
DNS resolve example.com	Resolves	ℹ️ DNS is unrestricted
CA cert	/etc/cloudflare/certs/cloudflare-containers-ca.crt exists	✅ Injected by runtime

Summary

• HTTP + HTTPS exfiltration fully blocked — deny-by-default with allowlist for api.openai.com and github.com
• Raw TCP to non-allowed hosts blocked — enableInternet=false prevents connections to hosts not in outboundByHost
• Raw TCP to allowed hosts on ports 80/443 — connects to the proxy (not the real host), which returns 403/resets. Data doesn't reach the destination.
• DNS still resolves — but without network access to blocked hosts, resolution alone doesn't enable exfiltration
• CA cert injected correctly by the Cloudflare runtime, enabling transparent HTTPS interception

The main remaining vector is DNS tunneling (encoding data in DNS queries to attacker-controlled nameservers). For the Codex use case this is a very low practical risk.

Note: interceptHttps requires the preview @cloudflare/containers@171 package — this pin can be removed once HTTPS interception ships in the stable release.

[andreisavu]

@scuffi would you consider this blocked on the upstream release of containers sdk before it can be merged? I think functionally we are in the right place now.

[andreisavu]

Screenshot from a manual test:

[gabivlj]

@andreisavu @cloudflare/containers@0.3.0 is being published!

[whoiskatrin]

@andreisavu following @gabivlj version release, we've released 0.8.8 with the containers version bumped, you should be able to try again now

[yasonk]

This is great! I just find it ironic that Claude Code generated a Codex app server :)

[sandy-bonk]

New commits pushed -- ok-to-test label removed. A maintainer must re-review and re-apply the label to run the full CI pipeline.

[andreisavu]

@whoiskatrin this PR is ready for another test

[andreisavu]

as far as automated checks go this seems ready to merge! let me know if more changes are needed.

[scuffi]

thanks for the example with the new functionality!

[andreisavu]

awesome! thanks for accepting the contribution!

[yasonk]

@andreisavu I wonder how you example would change with the recent releases of Sandbox features?
https://blog.cloudflare.com/sandbox-ga/

[andreisavu]

@yasonk not much I think from what I can tell from the GA announcement but there are definitely a lot more interesting things that can be done and built on top.

[yasonk]

@andreisavu ok, makes sense. Looks like you are using all the relevant features already. Super cool! The only enhancement would be to allow spinning up application on the sandbox and exposing the 3000 or 8080 port to allow e2e testing from the outside... but maybe that's just a matter of taste because you could just spin up an instance through CI automation and test it there.

Would something like this be doable for Claude? Or does Claude not allow this because that would be considered a 3rd party wrapper?