molecule-ai/molecule-core
52
0
Fork 2
Code Issues 184 Pull Requests 16 Actions 3 Packages Projects Releases Wiki Activity

RFC: codex container provisioner — add --cap-add NET_ADMIN so bwrap --unshare-net works (revert sandbox to workspace-write) #1693

New Issue
Open
opened 2026-05-22 23:38:43 +00:00 by hongming · 0 comments
hongming commented 2026-05-22 23:38:43 +00:00
Owner
Copy Link
Copy Source

Why

Codex CLI 0.130+ runs tool calls under bwrap with --unshare-net by default — codex tries to create a private network namespace, then sets up loopback inside it. Inside our docker container this fails with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

because the container doesn't carry CAP_NET_ADMIN. Even setting sandboxPolicy.network_access: True in the codex thread/start params doesn't help — bwrap still tries to bring up a netns and still fails.

Current workaround (in PR #30)

executor.py's sandboxPolicy is set to {"mode": "danger-full-access"} which bypasses bwrap entirely. Works, but loses the bwrap sandboxing (writable-root protection, filesystem allowlist, etc.).

Proper fix

molecule-controlplane provisioner adds --cap-add NET_ADMIN to the docker run args for codex template containers. Once that ships, revert executor.py to:

params["sandboxPolicy"] = {
    "mode": "workspace-write",
    "network_access": True,
}

and codex regains its proper sandboxing while still having network access.

Where to patch

molecule-controlplane — the function that emits docker run args for codex template workspaces. Look for the codex template branch in the provisioner; add NET_ADMIN to the cap-add list (others like T4's docker.sock + --privileged setup may already be there for the escalation leg; NET_ADMIN should be ADDITIVE).

Acceptance

  • docker inspect <codex-container> shows "CapAdd": ["NET_ADMIN", ...]
  • Inside container: bwrap --unshare-net --bind / / true exits 0 instead of Operation not permitted
  • Revert executor.py sandboxPolicy back to workspace-write + network_access:True via a template PR; codex agents still complete real Gitea-write turns
  • Smoke test: PM dispatches CR for a non-author PR review, CR successfully posts the review via Gitea API

Why a separate cap (not --privileged or --cap-add ALL)

  • NET_ADMIN narrowly allows netns + iface mgmt for bwrap; no extra footgun (no /dev/mem access, no SYS_ADMIN, no module load)
  • Auditable in docker inspect output

Related

  • PR #30 (template-codex) — the workaround currently shipping
  • The codex 0.130 schema/sandbox saga generally — see PR #30 description for the broader investigation

Owner

TBD. Estimated ~half day (provisioner change + smoke).

## Why Codex CLI 0.130+ runs tool calls under bwrap with `--unshare-net` by default — codex tries to create a private network namespace, then sets up loopback inside it. Inside our docker container this fails with: ``` bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted ``` because the container doesn't carry `CAP_NET_ADMIN`. Even setting `sandboxPolicy.network_access: True` in the codex thread/start params doesn't help — bwrap still tries to bring up a netns and still fails. ## Current workaround (in PR #30) executor.py's sandboxPolicy is set to `{"mode": "danger-full-access"}` which bypasses bwrap entirely. Works, but loses the bwrap sandboxing (writable-root protection, filesystem allowlist, etc.). ## Proper fix molecule-controlplane provisioner adds `--cap-add NET_ADMIN` to the docker run args for codex template containers. Once that ships, revert executor.py to: ```python params["sandboxPolicy"] = { "mode": "workspace-write", "network_access": True, } ``` and codex regains its proper sandboxing while still having network access. ## Where to patch `molecule-controlplane` — the function that emits docker run args for codex template workspaces. Look for the codex template branch in the provisioner; add NET_ADMIN to the cap-add list (others like `T4`'s docker.sock + --privileged setup may already be there for the escalation leg; NET_ADMIN should be ADDITIVE). ## Acceptance - `docker inspect <codex-container>` shows `"CapAdd": ["NET_ADMIN", ...]` - Inside container: `bwrap --unshare-net --bind / / true` exits 0 instead of `Operation not permitted` - Revert executor.py sandboxPolicy back to workspace-write + network_access:True via a template PR; codex agents still complete real Gitea-write turns - Smoke test: PM dispatches CR for a non-author PR review, CR successfully posts the review via Gitea API ## Why a separate cap (not --privileged or --cap-add ALL) - NET_ADMIN narrowly allows netns + iface mgmt for bwrap; no extra footgun (no /dev/mem access, no SYS_ADMIN, no module load) - Auditable in `docker inspect` output ## Related - PR #30 (template-codex) — the workaround currently shipping - The codex 0.130 schema/sandbox saga generally — see PR #30 description for the broader investigation ## Owner TBD. Estimated ~half day (provisioner change + smoke).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
approved
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 do-not-merge
hold from auto-merge (design review in progress)
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 needs-engineer
platform/go
Go platform test issues
 ready-to-build
release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
tier:high
High risk per dev-sop §SOP-6 — ceo only, 24h cooldown
 tier:low
Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve
 tier:medium
Medium risk per dev-sop §SOP-6 — managers/ceo can approve
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#1693
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?