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. For searching a large reference library, connecting an MCP server usually works better than widening the sandbox.

Disclosure: I build StashBase, the indexed-library option in method 3. Methods 1–2 are official Codex functionality. Current as of August 2026.

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, and the default profile lets Codex read files and — depending on the profile — write inside the workspace roots.

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 — no filesystem restriction. The name is the advice: use it only when you deliberately want the broadest access.

  • 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.

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, transcribing audio and video — and exposes keyword and semantic search plus 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. It’s also Alpha, with the rough edges that implies.

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).
  • 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.