Enable Codex sandbox network in template

Context

Codex Desktop can currently reach Neo's GitHub and A2A paths through escalated tool execution, but Chroma-dependent Memory Core / Knowledge Base calls fail inside the active workspace-write sandbox when local Chroma and embedding services remain correctly bound to loopback. The local repro from @neo-gpt showed:

• sandboxed curl to 127.0.0.1:8001, localhost:8001, 127.0.0.1:1234, and localhost:1234 returns HTTP_CODE:000
• escalated/outside-sandbox calls to the same Chroma and MLX endpoints return HTTP 200
• sandboxed query_raw_memories and add_memory fail with ChromaDB is not accessible
• escalated query_raw_memories and add_memory succeed
• a fresh codex debug prompt-input with [sandbox_workspace_write] network_access = true reports workspace-write with network enabled

This ticket exists to make the committed Codex template match the operator-approved local workaround while preserving the safer loopback service boundary.

The Problem

Without the template update, fresh Codex sessions copied from .codex/config.template.toml start with workspace-write filesystem access but network disabled for sandboxed commands. That makes Chroma-backed Memory Core / Knowledge Base work look like substrate failure even when the services are healthy on localhost.

Binding Chroma to 0.0.0.0 would be a faster but worse workaround: it widens service exposure to solve a Codex sandbox boundary problem. The better default is to keep Chroma / embedding services loopback-bound and let trusted Codex sessions reach local network services from the sandbox.

The Architectural Reality

• .codex/config.template.toml is the tracked Codex Desktop template.
• .codex/config.toml remains gitignored because it can contain machine-local paths, trust overrides, and environment-specific MCP settings.
• The template already forwards Neo MCP server environment variables for GitHub Workflow, Knowledge Base, Memory Core, and Neural Link.
• This change belongs to the Codex harness config substrate, not Memory Core service code and not Chroma launch configuration.

The Fix

Update .codex/config.template.toml to include:

[sandbox_workspace_write]
network_access = true

Add a short comment making the service boundary explicit: Memory Core and Knowledge Base use local Chroma / embedding services over loopback, and those services should stay bound to localhost.

Contract Ledger Matrix

Acceptance Criteria

• .codex/config.template.toml contains a [sandbox_workspace_write] block with network_access = true.
• The template comment explicitly preserves localhost / loopback service binding and does not recommend 0.0.0.0.
• git diff --check -- .codex/config.template.toml passes.
• codex debug prompt-input from the repo root reports workspace-write with network enabled after the template/local config is applied.
• The PR does not commit .codex/config.toml.

Out of Scope

• No changes to Chroma launch commands.
• No 0.0.0.0 binding.
• No Memory Core / Knowledge Base service changes.
• No attempt to solve the separate Knowledge Base output-schema issue where references[*].score is not numeric.

Avoided Traps

• Binding Chroma to 0.0.0.0: rejected because the failure boundary is Codex sandbox egress, not Chroma service health.
• Committing .codex/config.toml: rejected because local Codex config is intentionally ignored and machine-specific.
• Using a custom limited permissions profile as the default: rejected for this ticket because parser-level validation succeeded, but standalone macOS sandbox runtime validation was not reliable enough.

Related

• Discussion #10819 — config substrate cleanup / template-vs-local split.
• Prior Codex harness setup ticket #10485.

Origin Session ID: 17b1f1f7-5871-437b-b813-38d7ce6366c9

Handoff Retrieval Hint: "Codex Chroma localhost sandbox network_access config.template.toml"