Runaway Auto-review usage on Linux when bwrap/user-namespace sandbox initialization fails and a Codex-proposed legacy Landlock fallback becomes incompatible

What version of the IDE extension are you using?

26.814.41407

What subscription do you have?

ChatGPT Pro

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.8.0-100-generic x86_64 x86_64

What issue are you seeing?

This issue report has been written with the help of Codex itself.

<h2>Summary</h2><p>With <code dir="ltr">workspace-write</code>, <code dir="ltr">approval_policy = "on-request"</code>, and <code dir="ltr">approvals_reviewer = "auto_review"</code> (“Approve for me”), a Linux sandbox initialization failure caused routine workspace-local operations to be repeatedly converted into separate, quota-consuming <code dir="ltr">codex-auto-review</code> calls.</p><p>The affected environment did not have a distribution-provided <code dir="ltr">bwrap</code> executable. Unprivileged user namespaces were enabled at the kernel level, but restricted by AppArmor. Codex therefore attempted to use its bundled sandbox helper, which repeatedly failed with:</p><pre dir="ltr"><code>bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted</code></pre><p>A direct user-namespace test also failed with:</p><pre dir="ltr"><code>write failed /proc/self/uid_map: Operation not permitted</code></pre><p>These failures affected ordinary commands that should have run within the configured writable workspace, including file inspection, validation commands, and built-in editing operations.</p><p>Instead of recognizing this as a persistent sandbox initialization failure, Codex repeatedly followed this pattern:</p><pre dir="ltr"><code>routine workspace-local operation
-&gt; bwrap/user-namespace sandbox initialization failure
-&gt; retry with require_escalated
-&gt; separate codex-auto-review call
-&gt; reviewer returns allow
-&gt; command succeeds outside the sandbox
-&gt; next routine operation encounters the same failure
-&gt; repeat</code></pre><p>Because the reviewer overwhelmingly returned <code dir="ltr">allow</code>, the existing denial circuit breaker did not stop the loop. According to the current Auto-review documentation, a non-denial resets the consecutive-denial counter, so a persistent sandbox bug can produce an effectively unbounded number of successful approval reviews.</p><p>This appears to be the Linux equivalent of the failure-amplification pattern reported in #39408, but the underlying sandbox failure is different.</p><h2>Codex-proposed fallback and subsequent regression</h2><p>During an earlier troubleshooting session, the Codex agent diagnosed the sandbox failure and proposed, tested, and persisted the following global fallback:</p><pre dir="ltr"><code>[features]
use_legacy_landlock = true</code></pre><p>With a 0.147-series bundled CLI, this appeared to allow simple commands to run.</p><p>After the IDE extension/bundled CLI was updated to the 0.148 series and a managed permission profile was active, the persisted fallback became incompatible. Routine tool calls then failed with a panic equivalent to:</p><pre dir="ltr"><code>permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock</code></pre><p>This affected both shell commands and built-in editing operations.</p><p>Removing <code dir="ltr">use_legacy_landlock = true</code> stopped that compatibility panic, but immediately exposed the original <code dir="ltr">bwrap</code> failure again:</p><pre dir="ltr"><code>bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted</code></pre><p>Therefore, neither starting a new chat nor removing the legacy option resolves the underlying problem. The operating-system sandbox prerequisites and global Codex configuration persist across chats.</p><p>The problematic sequence was:</p><ol start="1"><li>The Linux sandbox could not initialize using the bundled helper.</li><li>Codex proposed a deprecated/legacy sandbox fallback.</li><li>Codex persisted that fallback in global configuration.</li><li>A later Codex update made the fallback incompatible with the active managed permission profile.</li><li>Tool calls began failing before normal command execution.</li><li>Removing the fallback restored the original sandbox failure.</li><li>Auto-review repeatedly approved escalated retries of routine operations.</li></ol><h2>Observed quantitative impact</h2><p>Over one affected nine-day period, local Codex rollout and usage records showed:</p><div><div><div>

Metric | Observed value
-- | --
codex-auto-review turns | 601
Reviewer decisions returning allow | 599
Reviewer decisions returning deny | 2
Aggregate reviewer input tokens recorded locally | approximately 66.8 million
Share of decisions returning allow | 99.7%

The aggregate token value is the sum of locally recorded reviewer input-token counts and was largely cached input. It is included to show the scale and repeated context growth; it should not necessarily be interpreted as an exact billable-token figure.

Two representative affected days showed:

Metric | Day A | Day B
-- | -- | --
Auto-review calls | 239 | 139
Escalated requests | 232 | 134
Clearly read-oriented or otherwise routine commands | at least 70 | at least 62
Input tokens in first reviewer call | 15,193 | 21,896
Input tokens in last reviewer call | 202,156 | 230,310
Maximum reviewer input observed | 240,855 | over 230,000

</div></div></div><p>On the two highest-impact days, the locally recorded aggregate reviewer input was approximately 33.2 million and 18.8 million tokens, respectively.</p><p>Older versions had already shown smaller amounts of sandbox-related review churn, so the Linux prerequisite incompatibility was probably pre-existing. However, the persisted legacy fallback and later CLI/permission-profile incompatibility substantially amplified the impact.</p><p>The important point is that nearly every review returned <code dir="ltr">allow</code>. This was not a rejection loop or repeated attempts to perform genuinely prohibited actions. It was repeated approval of routine work forced outside the sandbox by the same persistent initialization failure.</p><h2>Use case</h2><p>The workload consisted of long-running local agent sessions involving:</p><ul><li>reading and editing ordinary files under the configured writable workspace;</li><li>running syntax checks and validation commands;</li><li>inspecting logs and process state;</li><li>preparing and validating local scripts;</li><li>performing repeated but otherwise routine development operations.</li></ul><p>The operations identified above did not intentionally target protected configuration, credentials, system directories, or paths outside the configured workspace.</p><p>This use case makes the problem particularly expensive because a normal agent workflow can contain dozens or hundreds of small tool calls. If every call first fails sandbox initialization, each one can become a separate Auto-review model turn.</p>

What steps can reproduce the bug?

Reproduction A: repeated Auto-review calls from bwrap failure

Environment:

• Ubuntu 24.04
• VS Code Codex extension
• workspace-write
• approval_policy = "on-request"
• approvals_reviewer = "auto_review"
• no distribution-provided bwrap on PATH
• AppArmor restricting unprivileged user namespaces

Steps:

1. Open a normal writable workspace.
2. Select “Approve for me.”
3. Ask Codex to inspect or edit an ordinary file in that workspace.
4. Have Codex run a routine command such as:

   pwd

or:

   sed -n '1,20p' ordinary-workspace-file

1. The sandboxed command fails before executing normally:

   bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

1. Codex retries the command with require_escalated.
2. That retry creates a separate codex-auto-review turn.
3. The reviewer normally returns allow.
4. The escalated command succeeds.
5. Ask Codex to perform another routine workspace-local operation.
6. The same sandbox failure → escalation → Auto-review sequence repeats.

Starting a new chat does not fix the behavior because the operating-system sandbox state and permission configuration are unchanged.

Reproduction B: persisted legacy fallback becomes incompatible

1. On an affected Linux host, allow a Codex troubleshooting session to enable:

   [features]
   use_legacy_landlock = true

1. Confirm that an older bundled CLI appears to run simple commands using that fallback.
2. Upgrade to a version using managed permission profiles/direct runtime enforcement.
3. Start a new Codex session and run an ordinary command.
4. Observe a failure equivalent to:

   permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock

1. Remove the legacy setting.
2. Run the same command again.
3. Observe that the original bwrap initialization failure returns.

What is the expected behavior?

1. If the Linux sandbox cannot initialize, Codex should detect that condition once and clearly warn the user before beginning an agent workflow.
2. An internal sandbox initialization failure should not be treated as if every subsequent routine command independently requires a new security review.
3. Auto-review should have a circuit breaker for repeated equivalent allowed escalations, not only repeated denials.
4. Equivalent requests caused by the same sandbox failure class should be deduplicated or grouped.
5. After a small number of repeated sandbox-failure escalations, Codex should pause and tell the user that the environment is misconfigured instead of continuing to consume plan usage.
6. Reviewer context should not grow indefinitely when reviewing substantially identical retries.
7. Codex should distinguish between:

• a legitimate attempt to cross the configured sandbox boundary; and
• an operation that should be allowed inside the boundary but failed because the sandbox runtime itself could not start.

1. Codex should not persist a legacy sandbox backend as a global workaround without:

• checking compatibility with managed permission profiles;
• warning that it is deprecated or version-dependent;
• recording enough provenance to migrate or remove it safely after an update; and
• verifying the configuration after the update.

1. If an extension upgrade makes a persisted sandbox setting incompatible, Codex should migrate, disable, or clearly report that setting at startup instead of allowing every tool call to panic.
2. The UI should warn when abnormal Auto-review volume or reviewer-token growth is accumulating.
3. Usage attributable to repeated internal sandbox/tooling failures should be clearly separable from normal agent work and eligible for investigation or remediation.

Additional information

The official Linux sandbox documentation states that Codex falls back to a bundled helper when bwrap is missing, that the helper requires unprivileged user-namespace support, and that Codex surfaces a startup warning if bwrap is missing or the helper cannot create the required namespace.
In this case, the failure was repeatedly encountered during tool execution and amplified through Auto-review instead of being contained as a startup/configuration error.

Relevant documentation:

• Linux sandbox prerequisites and permission modes
• Auto-review behavior
• Related Windows report: #39408

Possible protections include:

• detecting repeated identical sandbox-startup failures;
• caching the failed sandbox health check for the session;
• preventing automatic escalation of every subsequent routine command;
• deduplicating equivalent approval reviews;
• adding a circuit breaker based on repeated approvals for the same failure class;
• bounding the transcript supplied to repeated reviewers;
• displaying a visible abnormal-usage warning;
• validating legacy sandbox options during extension upgrades;
• preventing an agent from silently persisting a version-sensitive global sandbox fallback;
• offering a supported temporary fallback only after explicit user consent.

I am not requesting that legitimate sandbox boundary crossings bypass review. The issue is that an internal sandbox/runtime incompatibility converted operations intended to remain inside the writable workspace into hundreds of separate Auto-review calls.
Raw rollout files are not attached because they contain unrelated private conversations, local paths, and project information. Redacted excerpts or additional aggregate diagnostics can be provided if maintainers specify which fields would help.
No username, hostname, repository name, source code, private document name, account identifier, or full local path is intentionally included in this report.