Codex Desktop Browser Use ignores persisted origin/upload approvals when nodeRepl.config is unavailable

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #23014

Powered by Codex Action

I also prepared a small public-repo patch that addresses an adjacent MCP elicitation persistence problem visible in this failure mode.

The Desktop bundled Browser/Chrome runtime source does not appear to be present in this public checkout, so this patch is not the full nodeRepl.config fallback fix described above. It does fix the public MCP path where a Guardian/auto-review ApprovedForSession decision is currently returned to the MCP server as a plain one-shot Accept, losing persist=session. For Browser Use style elicitations that support session persistence, that can produce repeated prompts on the auto-review path.

Local branch/commit prepared:

• branch: codex/preserve-mcp-elicit-session-persist
• commit: df376ed146aa952d405b915cfcf90d026d96d595

Patch summary:

diff --git a/codex-rs/core/src/session/mcp.rs b/codex-rs/core/src/session/mcp.rs
@@
 use codex_protocol::mcp_approval_meta::CONNECTOR_NAME_KEY as MCP_ELICITATION_CONNECTOR_NAME_KEY;
+use codex_protocol::mcp_approval_meta::PERSIST_KEY as MCP_ELICITATION_PERSIST_KEY;
+use codex_protocol::mcp_approval_meta::PERSIST_SESSION as MCP_ELICITATION_PERSIST_SESSION;
@@
-        ReviewDecision::Approved
-        | ReviewDecision::ApprovedForSession
-        | ReviewDecision::ApprovedExecpolicyAmendment { .. }
+        ReviewDecision::Approved | ReviewDecision::ApprovedExecpolicyAmendment { .. }
         | ReviewDecision::NetworkPolicyAmendment { .. } => ElicitationResponse {
             action: ElicitationAction::Accept,
             content: Some(serde_json::json!({})),
             meta: Some(mcp_elicitation_auto_meta()),
         },
+        ReviewDecision::ApprovedForSession => ElicitationResponse {
+            action: ElicitationAction::Accept,
+            content: Some(serde_json::json!({})),
+            meta: Some(mcp_elicitation_auto_meta_with_persist_session()),
+        },
@@
 fn mcp_elicitation_auto_meta() -> serde_json::Value {
@@
 }
+
+fn mcp_elicitation_auto_meta_with_persist_session() -> serde_json::Value {
+    serde_json::json!({
+        MCP_ELICITATION_APPROVALS_REVIEWER_KEY: ApprovalsReviewer::AutoReview,
+        MCP_ELICITATION_PERSIST_KEY: MCP_ELICITATION_PERSIST_SESSION,
+    })
+}

And the corresponding unit test assertion expects:

{
  "approvals_reviewer": "auto_review",
  "persist": "session"
}

I could not open the PR from this environment because there is no writable fork for this account, the GitHub connector cannot create branches in openai/codex (403 Resource not accessible by integration), and the local environment does not have gh or GitHub HTTPS credentials. Happy to submit the PR once a fork or GitHub CLI auth is available.

Follow-up from local reproduction/patch work:

• A fork was created at https://github.com/dianshili/codex.
• The prepared branch was pushed to dianshili:codex/preserve-mcp-elicit-session-persist at commit df376ed146aa952d405b915cfcf90d026d96d595.
• Compare URL: https://github.com/openai/codex/compare/main...dianshili:codex%2Fpreserve-mcp-elicit-session-persist?expand=1

I attempted to open a PR through gh pr create, GitHub REST, the GitHub connector, and the web compare page. The compare page reports that the branch is able to merge, but the upstream repository currently shows: “An owner of this repository has limited the ability to open a pull request to users that are collaborators on this repository.”

So the proposed fix is pushed and available for maintainers, but GitHub is preventing a non-collaborator PR from being opened against openai/codex.

I found a potentially deeper explanation for this failure mode in a current macOS Desktop build, though I cannot confirm that it is the cause of this specific report.

One important correction to the earlier diagnostic approach: ordinary model-submitted code receives a deliberately restricted globalThis.nodeRepl without config. Trusted, hash-approved Browser code receives a separate privileged bridge. Therefore, observing globalThis.nodeRepl?.config === undefined from ordinary code does not prove that the privileged bridge is absent.

In my reproduction, I attached a temporary debugger inside the trusted Browser client and observed its two privileged config reads separately:

• nodeRepl.config.readRequirements() succeeded with { requirements: null }.
• nodeRepl.config.readToml("browser/config.toml") rejected with Codex TOML directory must not be a symlink.

Here, ~/.codex itself is a symlink. The Browser client catches the exception and fails closed, making persisted Browser settings appear unavailable even though the trusted bridge exists.

I opened https://github.com/openai/codex/issues/35310 with the full evidence:

• https://github.com/openai/codex/issues/35310

If an affected installation in this thread uses a symlinked CODEX_HOME/~/.codex, the same rejection may explain its symptoms; otherwise this remains only an adjacent diagnostic finding.

Also related:

• #30947