Quick answer: Codex can read and write files in the workspace you launch it in. Outside that boundary it asks for approval, and OpenAI’s permission profiles let you widen or tighten what it may touch. Full access removes the boundary and the prompts; OpenAI recommends it only inside an isolated container or VM. For searching a large reference library, connecting an MCP server usually works better than widening the sandbox.

Method 1: Launch Codex where the files are

The zero-config option: cd into the folder and start Codex there. The working directory becomes the workspace. In a Git repository, Codex suggests writing inside the workspace and asking before anything else; in a folder that isn’t under version control, such as a notes folder, it suggests read-only, so pick a writable mode if you want it to edit (defaults).

Three built-in permission profiles set the boundary:

  • :read-only — local command execution stays read-only.

  • :workspace — writes allowed inside the active workspace roots and system temp directories.

  • :danger-full-access — removes local sandbox restrictions. The name is the advice; see how to give Codex full access before you use it.

  • Good for: working on one project at a time — the common case, and the default behaviour is designed for it.

  • Limits: one workspace per session. Reference material living elsewhere on disk means approval prompts or a broader profile.

(Launching Codex in a notes folder rather than a repo? There’s a second-brain guide for that setup.)

Method 2: Grant more directories with a custom profile

Codex’s config.toml supports custom permission profiles: extra workspace roots, per-path read/write/deny rules (deny your .env files, for example), activated with default_permissions = "your-profile". The exact syntax is in the permissions documentation.

  • Good for: a stable set of directories you always want Codex to reach — a second repo, a shared docs folder — with rules checked into config rather than approved prompt by prompt.
  • Limits: it’s still raw file access. Codex discovers files by listing directories and reading them; a folder of scanned PDFs or recordings has nothing it can grep.

How to give Codex full access

Full access turns off both the sandbox and the approval prompts. In the Codex CLI, start it with codex --yolo. In the IDE extension or the ChatGPT desktop app, choose Full access from the permissions control below the composer. Turning off the prompts alone is different: --ask-for-approval never keeps the sandbox, so Codex stops asking but stays inside its limits (approvals). OpenAI’s docs say to use full access only inside an environment that is already isolated, such as a container or a VM (CLI flags).

Usually a narrower setting fixes the actual problem:

  • Codex needs one more folder. Start it with codex --add-dir <path>, or add the folder to a custom profile (method 2). OpenAI suggests --add-dir over full access for this (safety tips).
  • Codex keeps asking about the same command, often git commit, because .git stays read-only inside the workspace (why). A rule (experimental) can allow that one command.
  • You want fewer prompts in general. Approve for me (codex --approve-for-me in the CLI) keeps the sandbox and sends approval requests to a reviewer agent instead of you. It uses extra model calls (automatic review).

Codex CLI. For one session:

codex --yolo

--yolo is short for --dangerously-bypass-approvals-and-sandbox. To keep full access as a preset you opt into, save a profile file and start Codex with codex --profile full_access:

# ~/.codex/full_access.config.toml
sandbox_mode = "danger-full-access"
approval_policy = "never"

These two lines are how OpenAI’s docs define full access. Put them in ~/.codex/config.toml instead and full access becomes the default for every session, in the CLI and in the IDE extension, which read the same file. If your config uses permission profiles (method 2), set default_permissions = ":danger-full-access" in place of sandbox_mode; Codex doesn’t mix the two (permissions).

IDE extension (VS Code, Cursor, Windsurf) and ChatGPT desktop app (Codex chats): open the permissions control below the composer and choose Full access (sandbox). If it isn’t listed, your version, setup or organization doesn’t offer it; managed machines can block it (permission modes).

With full access, Codex is no longer limited to your project folder, and OpenAI warns it “might perform unintentional destructive actions that can lead to data loss” (Windows app guide). Commands can also reach the network, and web search fetches live pages instead of OpenAI’s cached index, so instructions hidden in a page can steer what Codex does next (network access).

Method 3: Connect a search index over MCP

Codex is an MCP client, so instead of widening the sandbox you can hand it a library that’s already searchable. StashBase indexes folders you open — extracting text from PDFs, DOCX files, and images — and exposes keyword search, search by meaning once you add an OpenAI or OpenRouter key, and bounded file operations over MCP. In ~/.codex/config.toml:

[mcp_servers.stashbase]
command = "/Users/YOUR_USER/.stashbase/bin/stashbase-mcp"
# Windows:
# command = "C:\\Users\\YOUR_USER\\.stashbase\\bin\\stashbase-mcp.cmd"

Restart Codex after changing its MCP configuration. The StashBase app must be running — the MCP server lives in the app.

  • Good for: a standing reference library — papers, docs, transcripts — that Codex should search mid-task without you widening filesystem access to it. The same library serves Claude and any other MCP client.
  • Limits: it’s an app you run, not a flag you pass, and access is deliberately bounded to folders opened in the library.

Which one should you pick?

  • Working on one project → just launch Codex there (method 1).
  • A fixed set of extra directories, with guardrails → a custom permission profile (method 2).
  • No boundary at all, inside a container or VM → full access.
  • A large or mixed-format reference library → an indexed library over MCP (method 3). Same problem, same answer as for Claude and Cursor: raw access reads files, an index finds them.

How to reference a file in Codex

Type @ and pick the file. In the Codex CLI, @ searches your workspace and adds the file’s path to the prompt; the IDE extension supports @ mentions too (CLI shortcuts, prompting guide):

Summarize @research/interview-notes.md in five bullet points.
  • CLI: /mention <path> attaches a file to the chat, so later turns can refer to it too (/mention).
  • IDE extension: files you have open are included automatically. Select a passage to point Codex at just that part.
  • ChatGPT desktop app: attach the file to the chat (projects and chats).

@ only searches the workspace. For a file somewhere else, type its full path; whether Codex can open it depends on your permissions (method 2 adds the folder). If you don’t know which file you need, an index over MCP (method 3) lets Codex search for it by content.