---
id: 10820
title: Enable Codex sandbox network in template
state: CLOSED
labels:
  - enhancement
  - ai
  - build
  - model-experience
assignees:
  - neo-gpt
createdAt: '2026-05-06T15:48:11Z'
updatedAt: '2026-05-06T15:58:48Z'
githubUrl: 'https://github.com/neomjs/neo/issues/10820'
author: neo-gpt
commentsCount: 0
parentIssue: null
subIssues: []
subIssuesCompleted: 0
subIssuesTotal: 0
blockedBy: []
blocking: []
closedAt: '2026-05-06T15:58:48Z'
---
# 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:

```toml
[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

| Target Surface | Source of Authority | Proposed Behavior | Fallback | Docs | Evidence |
|---|---|---|---|---|---|
| `.codex/config.template.toml` Codex sandbox defaults | Codex config reference plus current `codex debug prompt-input` output | Trusted Neo Codex sessions start workspace-write with sandbox network enabled | Escalated `npm run ai:mcp-client` for Chroma-dependent tools | Inline template comment | `codex debug prompt-input` reports network enabled |
| Local Chroma / embedding service boundary | Operator preference and local connectivity matrix | Services remain loopback-bound; no `0.0.0.0` requirement | Temporary escalated commands if current session has stale sandbox policy | Inline template comment | Escalated localhost probes returned HTTP 200; sandbox probes failed before config refresh |

## 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"


## Timeline

- 2026-05-06T15:48:13Z @neo-gpt added the `enhancement` label
- 2026-05-06T15:48:13Z @neo-gpt added the `ai` label
- 2026-05-06T15:48:13Z @neo-gpt added the `build` label
- 2026-05-06T15:48:13Z @neo-gpt added the `model-experience` label
- 2026-05-06T15:48:14Z @neo-gpt assigned to @neo-gpt
- 2026-05-06T15:51:20Z @neo-gpt cross-referenced by PR #10821
- 2026-05-06T15:58:48Z @tobiu referenced in commit `af107d8` - "feat(codex): enable template sandbox network access (#10820) (#10821)

Co-authored-by: tobiu <tobiasuhlig78@gmail.com>"
- 2026-05-06T15:58:48Z @tobiu closed this issue

