Codex.app injecting restricted network access

Resolved 💬 4 comments Opened Feb 27, 2026 by samdeane Closed Jun 23, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.226.940 (720)

What subscription do you have?

Plus? The $20/month one!

What platform is your computer?

macOS 26.3 (25D125)

What issue are you seeing?

I’m seeing inconsistent sandbox/network behavior in Codex.app.

Although my local configuration has network enabled and I explicitly request elevated execution when needed, Codex sometimes runs with a later-injected permissions block that says network is restricted, which causes gh/API commands to fail unless escalated again.

My config.toml includes:

model = "gpt-5.3-codex"
personality = "pragmatic"
profile = "full_auto"

[profiles.full_auto]
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[profiles.readonly_quiet]
approval_policy = "never"
sandbox_mode    = "read-only"

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

[projects."/Users/sam/Developer/Projects/"]
trust_level = "trusted"

The project should be being treated as trusted as its path is /Users/sam/Developer/Projects/ActionStatus.

What happened

A command using gh failed with:
error connecting to api.github.com
In the same session, the effective permissions instructions included:
“Network access is restricted.”
Retrying with escalated permissions succeeded.

Why this is a problem

It makes behavior hard to predict from config.toml.
It’s unclear which policy source is authoritative (local config vs app-injected runtime policy).
It creates avoidable friction for normal GitHub workflows.

What steps can reproduce the bug?

Configure Codex with network enabled locally (for example via config.toml), then start a Codex.app session.
In the repo, run a GitHub API command in default sandbox mode, e.g. gh pr list --head <branch> --base main --json number,title,url.
Observe failure: error connecting to api.github.com (network unavailable in effective sandbox).
Check session-provided permissions context and note it includes Network access is restricted.
Re-run the same gh command with sandbox_permissions=require_escalated.
Observe success (command returns normal JSON output).
Re-run subsequent gh operations (e.g., gh pr create, gh pr view) with escalation and observe they also succeed.

What is the expected behavior?

My configured sandbox/network settings (and explicit sandbox_permissions usage) should be applied consistently.
If runtime policy overrides local config, that should be clearly surfaced in the UI/session metadata.

Additional information

Codex.app (desktop)
Repo workflow using gh CLI
Local config has network enabled, but effective session policy reported restricted network access

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 6 months ago

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

#12919

Powered by Codex Action

samdeane · 6 months ago

This may also be related to Codex.app not correctly parsing/using the rules I have defined in ~/.codex/rules.

See the following transcript:

User: what `gh` rules can you see

Assistant: In this session, I can only see one relevant rule set for command
approvals: the “Approved command prefixes” list in the runtime permissions
block. I do not see any approved `gh` prefix there. The visible approved
prefixes are things like `git ...`, `swift ...`, `rt`, and `ln -sfn`, but no
`["gh", ...]` rule.

User: did you load the github.rules file?

Assistant: No. I didn’t load any standalone `github.rules` file in this thread.
What I used was the runtime-provided permissions block (the “Approved command
prefixes” list) that the tool context exposed for this session.

User: can you show me the runtime-provided permissions block

Assistant: Yes. This is the runtime-provided permissions block that was active
in this session (verbatim key parts):

`<permissions instructions>`
`...`
`Network access is restricted.`
`...`
`## Approved command prefixes`
`- ["rt"]`
`- ["git", "add"]`
`- ["ln", "-sfn"]`
`- ["git", "pull"]`
`- ["git", "push"]`
`- ["git", "commit"]`
`- ["swift", "test"]`
`- ["swift", "build"]`
`- ["git", "push", "origin", "main"]`
`- ["swift", "run", "ActionBuilderTool", "."]`
`- ["swift", "package", "show-dependencies", "--format", "text"]`
`...`
`</permissions instructions>`

This is why `gh` had no preapproved prefix and why non-escalated network calls
failed.

User: What rules can you see in ~/.codex/rules

Assistant: These are the `gh` rules currently visible in
`~/.codex/rules/github.rules`:
- `prefix_rule(pattern=["gh", "pr", "create"], decision="allow")`
- `prefix_rule(pattern=["gh", "pr"], decision="allow")`
- `prefix_rule(pattern=["gh", "release", "create"], decision="allow")`
- `prefix_rule(pattern=["gh", "release", "edit"], decision="allow")`
- `prefix_rule(pattern=["gh", "release", "list"], decision="allow")`
- `prefix_rule(pattern=["gh", "release", "view"], decision="allow")`
- `prefix_rule(pattern=["gh", "repo", "create"], decision="allow")`

Also visible in `~/.codex/rules`:
- `default.rules`
- `git.rules` (symlink)
- `github.rules` (symlink)
- `misc.rules` (symlink)
- `swift.rules` (symlink)
- `xcode.rules` (symlink)

So your local rules do include `gh` allowances; the earlier mismatch was
between these local files and the runtime-provided “Approved command prefixes”
list for that session.

User: Why would the runtime-provided list not include the local rules?

Assistant: Most likely because the runtime list is not a direct dump of
`~/.codex/rules`, but an effective policy snapshot produced by the
app/orchestrator for that specific run. Common reasons include session snapshot
timing, layered policy precedence, mode-specific policy, partial exposure of
rules, rule-loading/symlink issues, and independent network restrictions. In
your case, local `gh` rules existed, but runtime still injected
`Network access is restricted` and a reduced approved-prefix list.

samdeane · 6 months ago

Similar to #12919 but I'm not certain it's an exact dupe, so I'm going to leave this one open.

ITMasterUK · 1 month ago

Hi, I have the same issue as of today. Sorry, I can see 2 issues closed as duplicate. Is there another open issue for this?