Custom profile allows localhost in CLI, but VS Code commands fail with EPERM

What version of the IDE extension are you using?

26.5908.31748 (pre-release), bundled Codex CLI 0.154.0-alpha.6.1. Also reproduced on 26.908.31748 with CLI 0.154.0-alpha.6.1, and 26.903.71938 with CLI 0.153.4.

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

Visual Studio Code 1.129.1

What platform is your computer?

macOS 26.6.2 on Apple Silicon.

What issue are you seeing?

The VS Code extension cannot connect to a local MongoDB instance at 127.0.0.1:27017, despite a custom permission profile that enables network access and explicitly allows localhost. MongoDB is running through OrbStack.

The same read-only database inventory succeeds both directly in a normal terminal and through codex sandbox --permission-profile local_workspace --include-managed-config. Inside the extension chat, it fails with:

MongoServerSelectionError: connect EPERM 127.0.0.1:27017 - Local (0.0.0.0:0)

An approved require_escalated retry fails with the same error. The extension log records the user approval response as {"decision":"accept"}. Direct access to the OrbStack Docker Unix socket also returns EPERM from the extension.

The permissions menu shows the custom profile selected, but a resume log reports:

responseActivePermissionProfile=:workspace
responseSandboxPolicy={"type":"workspaceWrite","networkAccess":false,...}

Subsequent turn logs report:

requestPermissionProfile=null
useAppServerPermissionDefault=true

Changing the approval option appears to leave the custom profile label selected. The small “Change permissions” popup is a tooltip. The logs show that the approval reviewer does change, but network access remains blocked.

The issue persisted across another chat, extension updates, app-server restart, and switching to the pre-release. The updated app-server and code-mode-host executable paths were verified running. A fresh Bash process with login disabled did not restore access.

The evidence shows a mismatch between the selected profile and execution behavior; the exact failing component has not been established. Names and paths in this report are anonymized.

What steps can reproduce the bug?

1. Use a macOS VS Code project with the Node mongodb package installed and a local MongoDB instance listening at 127.0.0.1:27017 (OrbStack in this case).

2. Configure a custom project permission profile in .codex/config.toml. The relevant TCP configuration, with the profile name anonymized, is:

default_permissions = "local_workspace"

[permissions.local_workspace]
extends = ":workspace"

[permissions.local_workspace.filesystem.":workspace_roots"]
".env" = "deny"

[permissions.local_workspace.network]
enabled = true

[permissions.local_workspace.network.domains]
"localhost" = "allow"
"127.0.0.1" = "allow"

The original profile also explicitly allows the local OrbStack Docker socket. There is no explicit legacy sandbox_mode override in the inspected config files, and no active network proxy was reported by the diagnostic. The project is trusted. The machine also has these managed requirements in /etc/codex/requirements.toml:

[permissions.filesystem]
deny_read = ["/**/.env", "/**/.env.*", "/**/*.env", "/**/*.env.*"]

3. Select the custom profile in the extension. Ask Codex to connect to the local MongoDB and list its databases using read-only queries. For a small probe, save this as mongo-probe.cjs in the project:

const { MongoClient } = require('mongodb');
const client = new MongoClient('mongodb://127.0.0.1:27017', {
  directConnection: true,
  serverSelectionTimeoutMS: 4000,
});

(async () => {
  try {
    await client.connect();
    const { databases } = await client.db('admin').admin().listDatabases();
    console.log('Connected. Database count:', databases.length);
  } catch (error) {
    console.error(`${error.name}: ${error.message}`);
    process.exitCode = 1;
  } finally {
    await client.close();
  }
})();

4. Compare these commands from a normal terminal in the project:

node mongo-probe.cjs
codex sandbox --permission-profile local_workspace --include-managed-config --cd "$PWD" -- node mongo-probe.cjs

In the observed setup, direct and named-profile inventory queries both succeeded. The probe above is a shortened version of that read-only inventory query.

5. Ask the extension agent to run node mongo-probe.cjs. The connection fails with EPERM. Ask it to retry with escalation and approve the request; the connection still fails.

6. Compare the custom profile displayed in the menu with the effective profile/network policy recorded in the resume and turn-start logs.

What is the expected behavior?

Commands in the extension should use the selected custom permission profile and connect to the explicitly allowed local service, consistent with the successful standalone sandbox test. The profile displayed in the UI should match the effective thread policy. Approval handling should not report success while leaving an approved connection blocked without explanation. Environment-file read restrictions should remain enforced.

Additional information

No response

Start with the custom profile in .codex/config.toml and the managed policy in /etc/codex/requirements.toml, then compare the standalone codex sandbox command with the VS Code resume and turn-start logs. Use mongo-probe.cjs and the extension logs to trace the selected profile, effective network policy, and approval result. Done means the extension uses the selected profile, permits the explicitly allowed local connection, and still enforces environment-file restrictions.