| name | setup-permissions |
| description | Scan the current repository's stack and propose scoped Codex sandbox, trust, and command-approval guidance for common test, lint, build, package, git, and external-tool workflows. Writes only after explicit approval. Global and project-agnostic. Trigger when the user says "set up permissions", "setup-permissions", "configure Codex permissions for this repo", "what permissions do I need", "allowlist commands for this project", or "configure Codex approvals". |
Set Up Codex Permissions
Review the repo and propose narrow Codex permission/config guidance before the user hits
repeated approval prompts. Treat permissions and sandbox settings as a security boundary.
Targets
Prefer the least invasive target:
- Project guidance in
AGENTS.md: default for documenting commands that should be
run and which ones need care.
- Project trust in
~/.codex/config.toml: only if the user explicitly wants this
repo trusted and understands it is personal machine config.
- Codex hooks or plugin config: only for deterministic automation that should always
run.
- Global config: only for genuinely global, user-approved behavior.
Do not silently edit ~/.codex/config.toml; show the exact change first.
Rule Of Thumb
Propose narrow, frequent, low-risk operations. Do not propose broad or destructive
allows.
Good examples:
- test commands from project manifests;
- lint/format commands;
- build/type-check commands;
- read-only
gh status and PR inspection;
- scoped package manager commands that do not publish or mutate global state.
Do not propose:
rm, sudo, force-push, destructive git reset/checkout, deploys, releases, publish
commands, secret reads, .env reads, or curl ... | sh;- broad shell rules that would cover unrelated commands.
Procedure
1. Orient
- Read existing
AGENTS.md, .codex/, .agents/, README, and manifests.
- Check whether the repo is already trusted in
~/.codex/config.toml if local access is
available.
- Do not treat Claude
.claude/settings*.json permission rules as Codex config; use
them only as hints about repeated workflows.
2. Scan The Stack
Read manifests/configs such as package.json, pyproject.toml, Makefile, justfile,
go.mod, Cargo.toml, CI workflows, lint/format config, and test config.
Identify:
- test runner;
- linter/formatter/type checker;
- build tool;
- package manager;
- GitHub/GitLab/other external tooling;
- commands likely to need network or writes outside the workspace.
3. Propose
Group proposals by category: tests, lint/format, build/type-check, package management,
git/GitHub, local tools, and documentation.
For each proposal include:
- command or config change;
- target location;
- what it enables;
- what it deliberately does not enable.
Include a "Deliberately not proposed" section for dangerous operations withheld.
4. Write Only Approved Changes
After explicit approval, apply only the selected changes. Preserve existing config and
dedupe entries. If the approved change is global/personal config, make the scope obvious
in the final report.
Guardrails
- Proposal first, write second.
- Never silently edit global Codex config.
- Never propose broad shell or destructive permissions.
- Merge, never clobber.
- Base every proposed command on files observed in the repo.
