›_ Codex Issues
Codex Issues / #16695

Feature request: per-automation sandbox/profile overrides (isolate permissions per automation)

Open 💬 4 comments Opened Apr 3, 2026 by TheAlexDev23
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App (MacOS)

What feature would you like to see?

Codex automations currently use default sandbox settings and global rules, which makes it hard to grant narrow permissions to a single automation without affecting normal interactive threads.

I have one recurring automation that needs network + one specific command prefix:
node .agents/skills/openclaw-skills-reddit-search/scripts/reddit-search.ts

I want this permission only for that automation, not globally for all threads.

Today:

  • Automations inherit default sandbox settings
  • Rules/prefix allowlists are global
  • There is no documented per-automation profile binding in automation.toml

This creates a security/usability gap:

  • Over-permissive: grant global allowlist and impact normal threads
  • Over-restrictive: keep strict defaults and break the automation

Any one of these would solve it:

  1. profile = "<name>" support in automation.toml (or UI equivalent)
  2. Per-automation sandbox/network/approval settings in UI + schema
  3. Per-automation command allowlist attached to automation config

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

  • #15310
  • #15751
  • #16167

Powered by Codex Action

TheAlexDev23 · 4 months ago

To my judgement, this issue doesn't seem to be a duplicate of the ones mentioned.

markymark2001 · 4 months ago

I need this too, and I want to also add my 2 cents onto this:

  1. There should be an easier way to configure automation permissions, right now its a big pain.
  2. I want to see automations with no restrictions - full machine access. I run automations for broad agentic tasks which require postgress, terminal, mcps etc., they also hit claude code for design work and its almost impossible to write rules for those.

ALSO. Important note: heartbeat automations don't solve this. Issue is that even though heartbeats inherit thread permissions, they have previous context in them which is a big downside. It errs the model to be lazy and focus on same issues instead of attacking new ones with fresh context - see screenshot attached. Prompting isnt too helpful - i can bypass the screenshot situation but the model is still steered toward older issues.....

<img width="797" height="276" alt="Image" src="https://github.com/user-attachments/assets/13c95590-5abf-4100-94d2-a5229981f345" />

Fengzdadi · 3 months ago

I ran into a similar problem around approval granularity and built a small experimental tool that may address part of this issue at the command-approval layer:

https://github.com/Fengzdadi/codexgo

CodexGo installs a Codex PermissionRequest hook and applies local allow/ask/deny policy rules before the normal approval prompt. For example, it can allow a specific command prefix, ask for sensitive commands, and deny dangerous patterns. It supports project-level and user-level scopes, so a recurring automation in a specific project can have narrower command policy than the global Codex user config.

To be clear, this does not fully solve the per-automation sandbox/profile problem described here. CodexGo is not automation-aware, and it does not provide per-automation network/sandbox isolation or an automation.toml profile binding. It only addresses the command-approval / allowlist side of the problem.

But it may be a useful workaround or reference implementation for the “per-automation command allowlist” part of this feature request.