fix(sandbox): gate implicit Dockerfile.odek builds behind operator approval

[jkyberneees]

Summary

Fixes the reported finding (verified against current code before fixing):

Sandbox auto-builds Dockerfile.odek from the working directory — MEDIUM. If Dockerfile.odek exists in the CWD, ResolveImage runs docker build automatically with the entire CWD as build context. Build-time RUN instructions execute outside the sandbox threat model: default capabilities, network enabled, and full read access to the build context. A malicious repository therefore gets host-adjacent code execution (and CWD exfiltration) merely by the user running odek inside it — while the analogous sandbox_image/sandbox_env project-config knobs correctly require explicit operator approval, this path had no approval gate.

Changes

1. Approval gate for implicit builds (cmd/odek/project_sandbox_approval.go)

approveProjectSandbox — already invoked at startup by run, repl, serve, telegram, subagent, schedule, and mcp — now also requires approval when sandbox is active, no explicit image is configured, and Dockerfile.odek exists in the working directory. It uses the same mechanism as project sandbox overrides:

• Interactive prompt (y = once, t = trust this project) with an explicit warning that docker build executes repo-controlled RUN instructions with the entire working directory readable as build context.
• Persisted approvals in ~/.odek/project_sandbox_approvals.json (0600), keyed on the project directory and the Dockerfile content hash — editing Dockerfile.odek invalidates a prior trust approval and forces re-review.
• ODEK_APPROVE_PROJECT_SANDBOX=1 bypass for CI; non-TTY runs without approval fail closed.

2. Build-time enforcement (cmd/odek/main.go::setupSandbox)

setupSandbox re-verifies approval (env bypass → persisted trust → in-process session approval) immediately before ResolveImage can build. This closes the gap the startup prompt alone would leave: a Dockerfile.odek introduced or modified after startup — e.g. written by the agent itself, then triggered via a serve-mode sandbox created per WebSocket connection — cannot be built unapproved. Skipped when an explicit image is configured (the Dockerfile is ignored then).

3. continueCmd gap closed (cmd/odek/main.go)

odek continue never called approveProjectSandbox, so project sandbox overrides were applied there with no approval at all (a pre-existing C-1 hole), and it re-enables the sandbox from the session. It now runs the same approval flow.

4. --network=none for builds by default (internal/sandbox/sandbox.go)

docker build now runs with --network=none, so RUN steps cannot fetch attacker payloads or exfiltrate build-context data over the network. ODEK_SANDBOX_BUILD_NETWORK=1 (operator-only — a project cannot set env vars for the odek process) opts back in for legitimate networked builds such as RUN apk add ….

Tests

• cmd/odek/project_sandbox_approval_test.go: requirement detection (sandbox off / explicit image / missing file → no gate), non-TTY fail-closed with actionable error, env bypass at both gates, once-approval covers the in-process build but does not persist, trust persists and content change invalidates it at both gates, no-Dockerfile no-op.
• internal/sandbox/sandbox_test.go: --network=none present by default, absent with ODEK_SANDBOX_BUILD_NETWORK=1.
• go test ./... -count=1 ✅ (28 packages), go vet ✅, golangci-lint run internal/sandbox/... cmd/odek/... → 0 issues ✅

Docs updated: docs/SANDBOXING.md (security callout on the Dockerfile.odek section), docs/SECURITY.md (new §18b), docs/CONFIG.md (env var table + example), AGENTS.md.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	odek	d581983	Commit Preview URL Branch Preview URL	Jul 26 2026, 08:40 AM