apply_patch cannot update existing files when sandbox helper fails with bwrap: loopback: Failed RTM_NEWADDR

What version of Codex CLI is running?

codex-cli 0.134.0

What subscription do you have?

ChatGPT Pro-lite

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.17.0-29-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

GNOME Terminal TERM=xterm-256color COLORTERM=truecolor No multiplexer intentionally in use.

Codex doctor report

{
    "schemaVersion": 1,
    "overallStatus": "ok",
    "codexVersion": "0.134.0",
    "checks": {
      "app_server.status": {
        "category": "app-server",
        "status": "ok",
        "summary": "background server is not running"
      },
      "auth.credentials": {
        "category": "auth",
        "status": "ok",
        "summary": "auth is configured",
        "details": {
          "auth storage mode": "File",
          "stored API key": "false",
          "stored ChatGPT tokens": "true",
          "stored agent identity": "false",
          "stored auth mode": "chatgpt"
        }
      },
      "config.load": {
        "category": "config",
        "status": "ok",
        "summary": "config loaded",
        "details": {
          "config.toml parse": "ok",
          "feature flags enabled": "28",
          "mcp servers": "4",
          "model": "gpt-5.5",
          "model provider": "openai"
        }
      },
      "installation": {
        "category": "install",
        "status": "ok",
        "summary": "installation looks consistent",
        "details": {
          "managed by bun": "false",
          "managed by npm": "true",
          "platform": "linux-x86_64"
        }
      },
      "mcp.config": {
        "category": "mcp",
        "status": "ok",
        "summary": "MCP configuration is locally consistent",
        "details": {
          "configured servers": "4",
          "disabled servers": "3",
          "stdio servers": "2",
          "streamable_http servers": "2"
        }
      },
      "network.env": {
        "category": "network",
        "status": "ok",
        "summary": "network-related environment looks readable",
        "details": {
          "proxy env vars": "none"
        }
      },
      "network.provider_reachability": {
        "category": "reachability",
        "status": "ok",
        "summary": "active provider endpoints are reachable over HTTP",
        "details": {
          "reachability mode": "ChatGPT auth"
        }
      },
      "network.websocket_reachability": {
        "category": "websocket",
        "status": "ok",
        "summary": "Responses WebSocket handshake succeeded",
        "details": {
          "auth mode": "chatgpt",
          "connect timeout": "15000 ms",
          "handshake result": "HTTP 101 Switching Protocols",
          "model provider": "openai",
          "supports websockets": "true",
          "wire API": "responses"
        }
      },
      "runtime.provenance": {
        "category": "runtime",
        "status": "ok",
        "summary": "running npm on linux-x86_64",
        "details": {
          "commit": "unknown",
          "install method": "npm",
          "platform": "linux-x86_64",
          "version": "0.134.0"
        }
      },
      "runtime.search": {
        "category": "search",
        "status": "ok",
        "summary": "search is OK (bundled)",
        "details": {
          "search command readiness": "file exists",
          "search provider": "bundled"
        }
      },
      "sandbox.helpers": {
        "category": "sandbox",
        "status": "ok",
        "summary": "sandbox configuration is readable",
        "details": {
          "approval policy": "OnRequest",
          "filesystem sandbox": "restricted",
          "network sandbox": "restricted"
        }
      },
      "state.paths": {
        "category": "state",
        "status": "ok",
        "summary": "state paths and databases are inspectable",
        "details": {
          "goals DB integrity": "ok",
          "log DB integrity": "ok",
          "state DB integrity": "ok"
        }
      },
      "terminal.env": {
        "category": "terminal",
        "status": "ok",
        "summary": "terminal metadata was detected",
        "details": {
          "COLORTERM": "truecolor",
          "DISPLAY": "present",
          "NO_COLOR": "1",
          "WAYLAND_DISPLAY": "present",
          "effective locale": "C.UTF-8",
          "terminal": "GNOME Terminal",
          "terminal size": "80x24"
        }
      },
      "updates.status": {
        "category": "updates",
        "status": "ok",
        "summary": "update configuration is locally consistent",
        "details": {
          "latest version": "0.134.0",
          "latest version status": "current version is not older"
        }
      }
    }
  }

What issue are you seeing?

apply_patch failed to update existing files while Codex was running with filesystem sandboxing enabled.

The error looked like a sandbox helper failure, not a patch syntax problem or a normal file permission problem.

Error:

apply_patch verification failed: Failed to read file to update <workspace-file>:
fs sandbox helper failed with status exit status: 1:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Related shell commands such as sed, rg, and git status also initially failed with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

For shell commands, Codex could recover by requesting elevated permissions. However, apply_patch does not appear to expose an escalation path, so the agent could not recover cleanly using the preferred patch tool.

Odd behavior: apply_patch was able to add new files earlier in the same session, but failed when updating existing files. After changing the session to danger- full-access, apply_patch worked normally again.

What steps can reproduce the bug?

1. Start Codex CLI in a repository with filesystem sandboxing enabled.

Example session policy:

• sandbox_mode=workspace-write
• network_access=restricted
• approval policy allows shell command escalations

1. Ask Codex to update an existing file using apply_patch.

Example patch shape:

* Begin Patch
* Update File: docs/example.md
@@
-old line
+new line
*** End Patch

1. The patch tool fails before applying the patch with:

fs sandbox helper failed ... bwrap: loopback: Failed RTM_NEWADDR: Operation
not permitted

1. Try reading files with shell tools such as sed, rg, or git status.

These may fail with the same bwrap error, but can be retried using shell
escalation.

1. Try apply_patch again.

There is no apparent escalation option for apply_patch, so the agent cannot
recover through the normal patch workflow.

1. Change the session permissions to danger-full-access.

1. Retry apply_patch.

apply_patch works normally.

What is the expected behavior?

apply_patch should be able to update existing files that are inside the
writable workspace when sandbox_mode=workspace-write.

If the sandbox helper fails, expected behavior would be one of:

• apply_patch reports a clearer recoverable sandbox error
• apply_patch exposes an escalation/retry path similar to shell commands
• apply_patch automatically falls back when editing files inside the declared

writable workspace

The agent should not need to use a script or another write workaround to edit
an existing file when apply_patch is the documented/preferred editing tool.

Additional information

The issue appears related to the Linux sandbox helper / bubblewrap path:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Impact:

• It blocked the preferred apply_patch workflow.
• Shell commands could recover with escalation, but apply_patch could not.
• A workaround required using a narrowly scoped script to edit an existing

file.

• Once sandboxing was changed to danger-full-access, apply_patch worked

normally.