Setup permissions

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.