You want to investigate an existing project's structure or bugs, without having its code edited, settings changed, or software installed. Prepare both an investigation prompt and permissions that restrict changes. Codex's read-only sandbox and Claude Code's Plan mode serve related purposes, but work differently.
Read → Show the evidence → Receive recommendations
Codex
Check read-only and the approval policyIn the app and IDE, check settings and the conversation's permissions display. In the CLI, use startup options to restrict writes by local commands.
Claude Code
Start with Plan; limit tools if neededInvestigate and plan, with source edits normally blocked. Check whether bypass is available at startup, and which commands and external tools remain available.
Checked against OpenAI's and Anthropic's official documentation on October 9, 2026. The startup examples in this article have not been run on a real machine. We distinguish documented product behavior from conditions you need to check in your own environment.
Check the settings screen and shared configuration. Check file write restrictions as well as the approval menu.
Select Plan in the interface. Separately check whether new conversations also start in Plan.
See Codex CLI, Claude Code CLI, or Claude on web and mobile. Check where execution takes place too.
1. Instructions versus permission restrictions
A request such as “Investigate problems in the login flow” leaves room for ambiguity: should the agent fix what it finds, or stop after reporting? Saying “Do not make changes” communicates your intention, but does not remove editing tools or the shell's ability to write.
Separate the intended task from controls that stop execution
Prompt
What you want it to doSpecify “Investigation and advice only. Do not implement.” Define the report format and when the task ends.
Product permissions
Which tools it may useUse Plan or tool restrictions to limit operations used for implementation. Check when approvals or mode changes can expand that scope.
Execution environment
How write destinations are protectedUse a sandbox or OS permissions to restrict actual writes. Check which processes are covered and which exceptions apply.
Claude Code's documentation explains that prompts and CLAUDE.md influence what the model attempts, while the permission system determines which actions are allowed. If you put prohibitions in Codex's AGENTS.md, likewise distinguish instructions from actual permissions. Source: Claude Code permissions.
2. Codex: app, IDE, and CLI settings
Desktop: check write restrictions in Settings
In the desktop app, open Settings → Configuration from the app menu. The settings shortcut is Ctrl+, on Windows and Cmd+, on macOS. The official Configuration screen shows Approval policy and Sandbox settings separately. Labels may vary by language and version.
Check approvals and write access separately
If Sandbox settings shows Workspace write, writes to the workspace are allowed. For investigation only, check for restrictions equivalent to read-only.
Approval policy controls how requests to run outside the restrictions are handled. Asking for approval alone does not prohibit edits within the workspace.
Before sending your request, check the permissions control below the input box and the active settings. Stop any existing work first if it is still running.
Sources: official Configuration screen, opening settings, permissions control below the input box.
If the interface is unclear: use Open config.toml
Open the configuration file through Settings → Configuration → Open config.toml. User settings usually live at ~/.codex/config.toml. With the legacy sandbox settings, these values select read-only access and a policy that does not request additional approval. This is a configuration example; simply reading the article does not change your settings.
sandbox_mode = "read-only"
approval_policy = "never"User settings also affect the app, IDE extension, and CLI that read the same configuration. Trusted project settings in .codex/config.toml, startup options, and managed policies can also apply, so finding these two lines is not enough to establish that they are active. In the CLI, /status and /debug-config can show execution conditions and where settings came from. To investigate for one session without changing persistent settings, use the CLI example below.
The newer Permission profiles feature is in beta and offers another configuration method, including the built-in :read-only profile. When combined with legacy sandbox_mode or --sandbox settings, legacy settings may take precedence; managed policies also introduce exceptions. Check which method you already use before adding both. Source: opening the configuration file, configuration precedence, Permission profiles.
Ask for approval does not prohibit editing
Ask for approval below the input box allows automatic work within the permitted workspace. Approve for me sends eligible approval requests to automatic review. Selecting either one does not make the workspace read-only. Full access is also unsuitable as an investigation-only restriction.
Codex also offers /plan to request a plan before implementation. However, check the planning request and the file write restrictions separately. Do not assume that Claude Code's Plan editing restrictions or exceptions also apply to Codex just because both use the same name. Source: Codex /plan.
IDE extension: open Codex Settings from the gear icon
Use the gear icon → Codex Settings at the top of the Codex sidebar to check shared settings, and Open config.toml for details. Check the permissions control below the input box too. The editor's extension settings are separate from the config.toml the agent reads. Disabling IDE context, which supplies open files, does not revoke the agent's permission to read files. Source: Developer settings by client.
CLI: set options for this session
If Codex CLI is already available, open a terminal in the folder you want to investigate and start it as follows. You do not need to permanently rewrite the configuration file. Your organization's managed policies and the capabilities of your CLI version still take precedence.
codex --sandbox read-only --ask-for-approval never--sandbox read-only
Select write restrictionsRead accessible files and run commands within a read-only sandbox.
--ask-for-approval never
Work within restrictions without askingDo not request additional approval. Have the agent report operations it cannot perform, rather than expand the restrictions to continue.
never does not mean full access. The sandbox type and approval policy are separate settings. OpenAI's official combinations table includes read-only with never for reading files and running commands within those restrictions. Source: Agent approvals & security.
How on-request differs
With --ask-for-approval on-request, the agent may request approval for an operation that needs to run outside the sandbox. Even if you start read-only, approving such an execution changes the original boundary. “Ask before making changes if necessary” and “Make no changes this time” are different policies.
Actions to avoid during investigation
Do not switch to Full access, select a writable profile, or approve execution outside the restrictions just to resolve an error. For an investigation-only task, reporting a check as not performed can be an appropriate outcome.
Web, Cloud, and Remote: distinguish the viewing device from the execution environment
Work on the web uses a managed execution environment and does not read your local Codex configuration file. Adding the two lines above on your PC does not, by itself, make Cloud execution read-only. Check the controls provided by the Cloud interface and workspace. We have not confirmed an equivalent startup procedure that makes all of Cloud read-only.
When using Remote to view work running on a PC from another interface, the settings that matter are those on the machine actually running the commands. Do not rely on restrictions applied only to the viewing device. See when to use Codex locally, through Remote, or in Cloud. Source: web versus local settings.
3. Use Claude Code only to investigate and plan
Claude Desktop: select Plan beside the send button in the Code tab
These instructions apply to Claude Desktop's Code tab. Chat and Cowork settings are not the same as Claude Code permission modes. The mode names below use labels from the official English documentation; the wording shown in the interface may vary by display language and version.
Check the execution environment and Plan before sending
Check whether Environment is Local, Cloud, SSH, or WSL, and whether Project folder is the folder you want to investigate.
Manual allows edits after approval; Accept edits approves edits automatically. Select Plan for investigation only.
Send the prompt below, read the plan, and stop. Keep Plan selected if you continue investigating.
Plan selected in the selector applies only to that session. Other mode selections are remembered per folder and override permissions.defaultMode in the settings file. If a new conversation should also be investigation-only, check that it shows Plan every time. Reading the same settings file as the CLI does not mean a conversation's mode choice carries over to the next session. Source: Desktop permission modes and persistence.
VS Code: select Plan from the mode indicator below the input box
Open Claude Code's chat panel and select the mode indicator below the input box → Plan. From v2.1.280 onward, you can also send /plan in the panel to switch. If the plan opens as a Markdown document, read it as an investigation result without approving implementation.
To start new conversations in Plan too
- Open VS Code settings (Ctrl+, on Windows/Linux; Cmd+, on macOS)
- Under Extensions → Claude Code, check the user setting for
claudeCode.initialPermissionMode - Set that user setting to
planif you want Plan as the initial mode - Open a new conversation and check that it actually shows Plan
Under the current official specification, the workspace setting for claudeCode.initialPermissionMode is ignored. This differs from behavior before v2.1.225. Selecting Plan in chat also affects only that conversation. Do not assume that putting permissions.defaultMode in the project's .claude/settings.json necessarily changes VS Code's initial mode. Check precedence among the extension's initial-mode setting, the last selected normal mode, managed settings, user settings, and other applicable configuration.
Watch for unsaved files too. The extension's claudeCode.autosave setting saves editor changes before Claude reads or writes. Distinguish AI source edits from files saved by the editor. Automatically attaching open files is also separate from restricting file access. Source: VS Code mode controls, extension settings, and precedence.
Web, mobile, and JetBrains controls
Select Plan from the mode menu near the input box. Cloud supports Accept edits and Plan. Auto requires organization permission and a supported model; Bypass permissions is unavailable.
In a Claude Code conversation, select a mode through “+” in the input box → Permission. With Remote Control, this also changes permissions for the active session on your local machine.
The plugin uses the CLI in the IDE's terminal. Use the CLI examples below and Shift+Tab; do not reuse VS Code-specific setting names.
Ordinary file edits are preapproved in Cloud, so do not treat it like Manual. Explicitly select Plan for investigation, and instruct the agent to stop after reporting instead of proceeding to implementation. Cloud's edit-approval behavior does not mean source files may be rewritten unconditionally while in Plan. Source: switching modes by interface, Cloud modes.
CLI: start in Plan and do not approve implementation
Start Claude Code CLI in Plan mode with the following option. Ordinary Plan reads files, investigates structure and problems, and plans proposed changes. Changes through source-editing tools are normally blocked, but plan files are created.
claude --permission-mode planStop after receiving the investigation results
In an interactive terminal, Shift+Tab switches modes. Also check whether bypass is available under the startup configuration.
Define completion as a report with target files and line numbers, rather than edits or a build.
Read the plan, or select No, keep planning to continue investigating. Yes options can exit Plan and proceed to implementation.
Shell commands in Plan are not universally limited to read-only commands. When auto mode is available and useAutoModeDuringPlan is on, a classifier can review and allow them. When auto is unavailable, among other cases, commands outside the built-in read-only set require approval. Source: Plan in Permission modes.
Some conditions remove the editing block even in Plan
According to the official documentation, Plan's editing and command restrictions are not enforced in interactive terminal sessions where bypass is available. Attempted edits or commands may execute even while the interface shows Plan. Check startup options and settings that enable bypass rather than relying solely on the Plan indicator. -p, the SDK, and the VS Code chat panel have separate explanations; do not generalize this exception to every interface. Source: bypassPermissions.
If you want neither shell commands nor editing tools
If reading code and investigating structure are enough, use --tools to restrict built-in tools. This example limits file investigation tools to Read, Glob, and Grep, and also denies MCP tools. EndConversation remains available to end the conversation. This narrows the investigation capabilities compared with ordinary Plan: checks requiring command execution become unavailable.
claude --permission-mode plan --tools "Read,Glob,Grep" --disallowedTools "mcp__*"Do not substitute --allowedTools here. That option specifies tools allowed without confirmation; it does not restrict the available tools to that list. Also, --tools alone does not restrict MCP, so a separate option is needed. Source: CLI reference.
Desktop has no session-level UI controls equivalent to the CLI's --allowedTools or --disallowedTools. Permission rules in settings files apply, but the Plan button alone does not produce the same restrictions as this tool-limited example. Source: Desktop versus CLI capabilities.
This example does not make your entire PC read-only, including the app's own saved data or loaded settings and hooks. When opening an unfamiliar project, separately check existing hooks, plugins, and external connections. For stricter operation, --restricted, available from v2.1.248, changes more than the tools: it also changes which settings are loaded, among other things. It is not another name for Plan using your usual environment unchanged.
For ongoing tool-permission management, see Claude Code allow, ask, and deny settings. For Bash isolation, see sandbox configuration and limits. Isolation that permits workspace writes by default serves a different purpose from investigation-only use.
4. A ready-to-use investigation prompt
Once permissions are in place, ask the agent to stop after reporting. Defining what to investigate and what output completes the task more precisely than “Fix this” or “Improve this” reduces misunderstandings that lead to implementation.
For this task, investigate the current state and provide advice only. Do not implement.
Scope: This project's login flow and authorization boundaries.
Allowed: Read accessible source files and explain the structure and problems.
Prohibited: Creating, editing, or deleting files; changing settings; adding dependencies;
builds, tests, database operations, commits, pushes, deployments,
or changes to external services.
Do not expand permissions to run hooks or scripts.
Deliverables:
1. The processing flow, with investigated files and line numbers
2. Evidence, impact, and priority for each potential issue
3. Proposed improvements, without executing them, and checks needed before implementation
4. Questions that reading alone cannot resolve, and checks not performed
Even if a change is needed, stop at the recommendation and do not execute it.
End the task once you have submitted the investigation report.“Investigate possible causes of saved data disappearing by reading the save, load, and exception-handling code.” If logs contain secrets, decide what may be shared first.
“Explain module dependencies and identify overlapping responsibilities.” Do not include actual refactoring in the deliverables.
“Read ownership checks, authentication, authorization, and input validation.” Treat running attack code or sending requests to production as separate tasks.
Even if you agree with a proposed improvement, you can reply in the investigation conversation: “Keep this as a candidate approach. Do not implement it.” To proceed, start a separate development conversation with newly defined scopes for changes, tests, and publication. This keeps investigation restrictions aligned with the task's purpose.
5. What to check before and after
Do not stop verification at “The model said it changed nothing.” Nor do you need to try writing to the source you want to protect just to check that it is unchanged. Start with the interface, configuration explanations, and existing diffs, and record anything still uncertain.
Before: align the purpose and execution conditions
- Check the target folder and what information the agent may read
- For Codex, check file permissions and approval policy; for Claude Code, check Plan and startup conditions for bypass
- Check whether the same mode persists in new conversations and whether shared settings affect other clients
- Define the operations allowed during investigation, including shell, MCP, browser, and external apps
- Identify your existing uncommitted changes and untracked files, and preserve a baseline for comparison
- Make report submission the completion condition, and require checks blocked by permissions to be reported as not performed
If the project uses Git, compare the diffs
For example, these commands show changed files and summaries of staged and unstaged diffs. Check both before and after the investigation so that you do not mistake your pre-existing changes for AI changes. This example assumes that the target repository already uses Git.
git status --short
git diff --stat
git diff --cached --statThese commands do not prove that nothing changed anywhere. git diff does not show untracked files, and the checks do not cover all ignored files, locations outside the workspace, databases, or external services. Final diffs also cannot reveal an operation that changed something and then restored it. In the report, distinguish what you checked from what you did not check. Official Git documentation: git status, git diff.
After: read the report as findings, not implemented fixes
- Does each potential issue include files, line numbers, and evidence from the code?
- Are conclusions from static reading distinguished from actual reproduction or test results?
- Are there any unexplained changes in the before-and-after diffs?
- Are checks blocked by insufficient permissions or execution prohibitions clearly listed?
- Are next steps still proposals, without being started automatically?
6. Checks you cannot run and remaining risks
Tests and builds can also write files
Even without editing code, tests may write temporary files or snapshots, builds may create artifacts, and package managers may write caches or dependencies. Do not assume that “only running tests” changes nothing. A failure under read-only restrictions may be the intended result of those restrictions rather than a bug.
If a report concludes that authorization might be bypassed under certain conditions, the next step can be a reproduction plan in a separate verification environment. Improving an investigation does not require immediately allowing writes to a production database or a machine containing secrets. Separating what static inspection can establish from what requires execution makes the report more useful for decisions.
Source write restrictions alone do not protect these areas
Information the agent is allowed to read may be used in its investigation. Read-only access and denying reads of secret files are separate controls.
MCP or connected apps may be able to modify tickets, repositories, and other resources. Local restrictions alone do not establish that every route is blocked.
Saving conversations and plans is separate from editing the target source files. These startup examples do not eliminate every write on your PC.
Codex network restrictions also distinguish communication by sandboxed commands from service traffic for models, authentication, and other purposes. Starting read-only does not guarantee that information read will not be sent to the model or used for training. Source: scope of Permissions. For blocking secret reads, see Codex secret files and permissions. For training and retention settings, see ChatGPT and Codex training use and privacy.
When restrictions do not work as expected
- A setting is missing: Check your product, version, execution environment, and organization's managed restrictions. Do not switch to settings that bypass those restrictions.
- A test fails: Distinguish a required write from a code problem. Keep checks not performed in the report.
- You added restrictions midway: Changes already made are not reversed. Stop ongoing work, check the diffs, and then start a new investigation conversation.
Summary
For Codex, specify read-only and an approval policy. For Claude Code, check Plan's startup conditions and restrict available tools if needed. Then provide a prompt that ends the task after report submission. Both tools can be used with investigation and execution of changes kept separate.
If strict restrictions leave some questions unanswered, accept the list of checks not performed and a proposal for further verification rather than casually switching to full access. Controls over readable information, external tools, and the app's own saved data need a separate design from prohibiting source edits.
FAQ
Does asking “Investigate only” make the agent read-only?
It communicates the goal, but does not change actual editing capabilities or command permissions. Along with the prompt, use Codex's sandbox or Claude Code's Plan and tool restrictions, and check exactly what they limit.
Does Claude Code Plan guarantee that no files will change?
No. It normally blocks source edits, but creates plan files. The official documentation also states that Plan restrictions are not enforced in interactive terminal sessions where bypass is available. It is not a mode that prohibits every write on your PC.
Does Codex's “never” approval policy mean unrestricted access?
It means no approval requests; it does not disable the sandbox. Combined with read-only, the agent investigates within those restrictions. Distinguish this from starting with full access.
Does a read-only investigation complete a security review?
No. Potential issues found by reading source are different from results reproduced through execution. Conclusions remain limited if configuration, the runtime environment, or dependent services cannot be checked. Report the evidence and unknowns, and plan any necessary demonstration in a separate verification environment.
Does Ask for approval in the Codex app prevent editing?
Not by itself. Approval policy and file write restrictions are separate. Check Configuration and active permissions, and use restrictions equivalent to read-only for investigation-only work.
If I select Plan once in Claude Desktop or VS Code, will it apply next time?
Plan selected through the selector applies only to that conversation or session. Check the indicator every time. In VS Code, you can use the user setting claudeCode.initialPermissionMode to specify the initial mode.
