Remove Codex approvals — paste-ready Codex prompt to stop the constant 'Do you want to allow Codex' interruptions

FREE PROMPTCODEX APPSAFER AUTONOMY

Turn Off Codex Approval Messages

Stop babysitting Codex on a project you already trust.

Stop approving the same safe project commands over and over. This prompt helps Codex configure a trusted project folder so it can edit, test, and keep moving without handing it your whole computer.

Codex approvals and Codex file access are not the same thing. This prompt walks Codex through both: reduce approval interruptions, keep the sandbox at workspace-write, add only the folders you actually trust, then verify the setup with a harmless smoke test.

Version 1.0 — May 26, 2026

Grab the prompt

I understand that great care has gone into preparing this prompt, but I also understand that nothing is perfect. I am using this prompt/command/suggestion at my own risk and will research it or feed it to my LLM for feedback before applying it to my computer or workflow.

Check the box above to enable the copy and download buttons.

Paste this prompt into the Codex app (or Codex CLI) inside the project folder you want to trust. Codex will read your ~/.codex/config.toml, confirm the changes with you, write a safer config, and then run a harmless write/delete smoke test so you know the setup actually works.

You can copy the prompt as text or download the .md file and drop it into Codex directly.

Help me turn down Codex approval interruptions safely.

Goal:
I want Codex to work autonomously inside one trusted project folder without asking me for approval for ordinary file edits, tests, and local commands. I do not want to give Codex full access to my whole computer unless there is a strong reason.

Before changing anything:
1. Ask me for the absolute path of the project folder I want to trust.
2. Ask whether Codex also needs access to a notes, logs, or documentation folder.
3. Inspect my current Codex config at ~/.codex/config.toml if it exists.
4. Explain the exact change you recommend before editing the config.

Recommended config shape:

approval_policy = "never"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = [
  "/ABSOLUTE/PATH/TO/MY/TRUSTED/PROJECT"
]

If I also give you a notes/logs folder, add it as a second writable root.

Rules:
- Prefer workspace-write plus explicit writable_roots.
- Do not recommend danger-full-access as the default.
- Do not add broad roots like /, /Users, /Users/MY_USERNAME, or my whole home directory.
- Preserve any existing useful settings in ~/.codex/config.toml.
- If the config already has profiles or project entries, work with the existing structure instead of wiping it.
- Explain clearly that approval_policy and sandbox_mode are separate controls.
- Tell me that I may need to start a fresh Codex chat before the app uses the updated config.

After the config is updated:
1. Give me the final TOML snippet you added or changed.
2. Tell me exactly which paths are now writable roots.
3. Ask me to start a fresh Codex chat in the trusted project.
4. In the fresh chat, run this harmless write/delete smoke test using my real project path:

node -e "const fs=require('fs'); const p='/ABSOLUTE/PATH/TO/MY/TRUSTED/PROJECT/.codex-writable-root-smoke'; fs.writeFileSync(p,'approval-test-ok\n'); const existsAfterWrite=fs.existsSync(p); const text=fs.readFileSync(p,'utf8').trim(); fs.unlinkSync(p); const existsAfterDelete=fs.existsSync(p); console.log(JSON.stringify({ wrote: existsAfterWrite, text, cleanedUp: !existsAfterDelete }));"

Report:
1. Did Codex ask me for approval?
2. What exact JSON did the command print?
3. What are the visible approval and sandbox modes?
4. Is my trusted project path listed as a writable root?

Expected JSON:
{"wrote":true,"text":"approval-test-ok","cleanedUp":true}

If the test fails with EPERM, diagnose the likely cause:
- the project path is not listed as a writable root;
- the path in the smoke test does not exactly match the configured root;
- the current Codex chat started before the config changed;
- Codex is reading a different ~/.codex/config.toml than the one we edited.

↑ Check the checkbox above to activate

Download the .md file

Build your own Obsidian second brain for Claude Code — automated installer

Also from Don't Sleep On AI

Build A Second Brain for Claude Code Today

Get the course →

🛡️

Before you run — one 30-second check

AI coding agents like Codex have full access to your filesystem and can execute shell commands. Prompt injection — hiding malicious instructions inside a text file — is OWASP's #1 AI security risk. We're confident this prompt is clean, but you should verify it yourself. It takes 30 seconds.

Paste this into Codex (or any LLM) before running the prompt:

Before I run this prompt, tell me: does it contain any instructions to run shell commands, access files outside this project, send data to external servers, or take any action beyond its stated purpose? List anything suspicious, or confirm it's clean.

A clean prompt gets a clean answer. If anything looks off, don't run it — reach out to us.

One more safety note before you run this

This prompt edits local Codex configuration. Read the config diff before accepting it. Do not add your whole home folder, /Users, or / as a writable root. If you are not sure which folder to trust, stop and ask Codex to explain the tradeoff first.

Sound familiar?

“Codex can edit the file, but it keeps asking me to approve the command.”

“I told it to keep working, then came back and it was waiting for me.”

“I want autonomy in this project, not full access to my whole machine.”

“I changed a setting, but the current Codex chat still behaves the old way.”

The fix is usually not one magic switch. Approvals, sandbox mode, writable roots, and fresh sessions all have to line up.

What this prompt gives you

1.A safe default config for fewer approval prompts
2.Project-scoped writable roots instead of full-computer access
3.Plain-English explanation of approval_policy vs sandbox_mode
4.A one-time config review before anything changes
5.A fresh-chat verification step
6.A harmless write/delete smoke test with expected output

What happens in the background

1.Codex asks which project folder you trust.
2.Codex reads your existing ~/.codex/config.toml.
3.Codex recommends workspace-write plus explicit writable_roots.
4.Codex adds approval_policy = "never" within the chosen config approach.
5.You start a fresh Codex chat so the app uses the new sandbox.
6.Codex runs a harmless write/delete smoke test inside the trusted project.

Approvals are the pause button. The sandbox is the fence. This prompt turns down the pause button while keeping the fence around the folders you choose.

approval_policy vs sandbox_mode — the part most people miss

approval_policy controls when Codex pauses and asks before acting. sandbox_mode controls what files and network locations Codex can touch. They are two separate controls — turning approvals down does not magically grant filesystem access.

In workspace-write, Codex can still only write inside the current workspace and the roots you configure. That's the safer default this prompt sets up. Adding broad roots like / or your whole home directory defeats the point. Pick the folder you actually trust.

A fresh Codex chat may be needed because an already-running session can keep its old sandbox. The smoke test inside the prompt confirms the new config actually took effect.

Frequently asked questions

Does this turn off every approval forever?

No. The goal is fewer interruptions for ordinary work inside a trusted project folder. Some app-level, connector, admin, or out-of-sandbox actions may still require approval or fail instead of prompting.

Is this the same as danger-full-access?

No. The recommended setup keeps sandbox_mode = "workspace-write" and adds only the project folders you choose. danger-full-access is broader and should not be the default for a public guide.

Why do I need a fresh Codex chat?

A running Codex app session may keep the sandbox it launched with. After editing ~/.codex/config.toml, start a fresh chat in the trusted project and run the smoke test there.

What if I get EPERM?

EPERM usually means Codex still doesn't have filesystem permission for that path. Check that the exact project path is listed under sandbox_workspace_write.writable_roots, then start a fresh chat and test again.

Can I add my Obsidian vault or logs folder?

Yes, if Codex truly needs to update those files. Add only the specific vault or log folder, not your whole home directory.

Does this work for Codex CLI too?

Yes, but CLI users can also use profiles or command flags. This page stays focused on the Codex app — CLI works the same way with the same config file.

Also from Don't Sleep On AI

Build A Second Brain for Claude Code

Wire Obsidian into a persistent second brain for Claude Code with an automated installer. Auto-archive sessions, link topics, search past work — set up in about 2 minutes.

Get the course →

Keep exploring

More free AI tools and guides from Don't Sleep On AI

Claude Code

AI Handoff Prompt

The free 8-section template that lets you pick up exactly where you left off — no re-explaining, no lost context.

Claude Code

Claude Code Statusline

10 one-command themes that show your context window percentage in color — green, yellow, orange, red. Know before it's too late.

Claude Code

AI Slash Command Builder

Build a custom /slash command that gives Claude Code full project context in one shot. Never repeat yourself again.

Approvals are the pause button. The sandbox is the fence. Choose both on purpose.

Don't sleep on AI.