When to Use Agent vs Ask Mode

Agent vs Ask mode is the choice between two stances toward an AI coding tool — read-only analysis and read-write execution — with a third, unattended tier beyond them. Cursor calls the first two Ask and Agent, Claude Code calls them plan and normal mode, Codex calls them read-only and workspace-write sandboxes. Picking the wrong point wastes context or ships unreviewed edits.

You ask a quick question about your Express payment handler — “why does processPayment sometimes double-charge?” — and thirty seconds later the agent has silently rewritten four files, changed the Stripe idempotency logic, and edited a migration you never wanted touched. Now you are reviewing a diff you did not ask for, on a critical path, under time pressure.

The same mistake costs you the other way round. Open the tool in its default agent mode to ask “how does payment processing work here?” and it starts reading files and running greps, burning 40,000 tokens of context before producing a three-sentence answer you could have had for a fraction of that.

Both are mode problems, not model problems. Every modern coding tool exposes the same spectrum — read-only exploration, guided execution, unattended autonomy — and using the wrong point on it is the fastest way to turn a five-minute question into an hour of cleanup.

What mode discipline gives you

A clear mapping of the three modes across Cursor, Claude Code, and Codex
The exact toggle, flag, or approval policy for each one
A two-phase workflow (explore read-only, then execute) that stops the agent editing files you never agreed to touch
A copy-paste exploration prompt that produces a reviewable refactor plan without changing a line
A scoped execution prompt that limits the agent to one step, with a hard stop before it continues
Decision criteria for when autonomy is safe, and the failure modes when it is not

The mode spectrum across the three tools

Two stances do most of the work. Read-only is the explorer: the agent searches the codebase, reads files, traces call sites, and answers questions, but cannot edit anything or run mutating commands. Use it to build an accurate shared understanding before any code changes. Read-write is the implementer: the agent edits files, runs commands, and fixes errors to carry out a plan you have already approved. Beyond them sits a third tier — unattended execution — which is worth its own decision rather than being treated as “agent mode with fewer prompts”.

Capability	Cursor	Claude Code	Codex
Read-only analysis	Ask mode (or Plan mode to draft a plan)	Plan Mode (Shift+Tab)	`--sandbox read-only -c approval_policy=on-request`
Guided execution	Agent mode (default)	Normal Mode (default)	`--sandbox workspace-write -c approval_policy=on-request`
Unattended, sandboxed execution	Auto-Run “Run Everything” / Cloud Agent	`--dangerously-skip-permissions` / Sandbox	`--sandbox workspace-write -c approval_policy=never` (trusted runs only)

Read-only analysis mode

Use this when you want to understand code without modifying it. The agent reads files and answers questions but cannot make changes.

Select Ask in the mode dropdown at the bottom of the chat input. The agent will analyze code and answer questions without making changes. @-mention the files you care about (@src/routes/payments.ts) so it starts from precise context. For investigations that should end in a written plan rather than edits, Plan mode is the sibling to reach for:

How does the authentication flow work? Trace the request from
the login endpoint through middleware to the session store.
Show me the key files and functions involved.

Ask mode is token-efficient because the agent focuses on answering your question rather than exploring broadly. It uses the codebase index for retrieval rather than reading files one by one.

Toggle Plan Mode with Shift+Tab — the cycle runs Normal, Auto-Accept, Plan, and ⏸ plan mode on appears at the bottom of the terminal. You can also launch straight into it with claude --permission-mode plan. Claude reads files and explores the codebase but cannot write to any file or run destructive commands:

Explain the authentication flow. Start from the login endpoint
and trace through middleware, session management, and token
refresh. Identify the key files and any potential issues.

Plan Mode is particularly useful for code reviews and architecture analysis. Claude can read as many files as needed without risk of accidental modification.

Use a read-only sandbox so Codex can browse and reason but cannot edit files. Keep approval_policy=on-request explicit: the approval policy controls escalation prompts, while the sandbox enforces the filesystem boundary:

codex --sandbox read-only -c approval_policy=on-request \
  "Explain the authentication flow in this codebase. Trace the request \
   lifecycle from login to session creation. Identify key files and \
   potential security concerns."

In the Codex IDE extension, choose a read-only planning workflow when you want analysis without edits.

Best for: Code review, architecture analysis, onboarding to a new codebase, understanding unfamiliar code, investigating bugs before fixing them.

Guided execution mode

The default mode for all three tools. The agent reads files, makes changes, and runs commands, but asks for permission at key points. This is the workhorse mode for most development tasks.

Agent mode is the default. Cursor reads files, proposes edits, and runs terminal commands, writing a checkpoint before each set of edits so a bad step is a rollback rather than a repair job. Review in the diff view and accept or reject per hunk — bulk-accepting is how off-plan edits get in:

Implement the rate limiter middleware following the pattern in
@src/middleware/auth.ts. Write tests in @src/middleware/__tests__/.
Run the tests after implementation.

Configure which tools the agent can use in Cursor Settings. You can allow file edits but require approval for terminal commands, or vice versa.

Normal Mode is the default: Claude asks permission for file writes and potentially destructive commands, but reads files freely. Shift+Tab into accept-edits (⏵⏵ accept edits on) to auto-apply file edits while still being prompted for shell commands:

Implement the rate limiter middleware following the pattern in
src/middleware/auth.ts. Write tests and run them. Fix any
failures before finishing.

Tune the permission level with /permissions. Allowing specific safe commands (like npm test) reduces interruptions while keeping approval for destructive operations.

Run with workspace-write and on-request configured explicitly. Routine reads, edits, and commands allowed by the workspace sandbox proceed without a prompt; Codex asks when it needs to cross the sandbox boundary:

codex --sandbox workspace-write -c approval_policy=on-request \
  "Implement the rate limiter middleware following existing patterns. \
   Write tests and run them. Fix any failures."

For tighter filesystem control, keep approval_policy=on-request and switch the sandbox back to read-only. Reserve danger-full-access for disposable, explicitly trusted environments. In the IDE extension, Codex shows inline diffs for each proposed change — accept or reject individual hunks rather than whole files.

Best for: Feature implementation, bug fixes, refactoring, test writing, most day-to-day development work.

Full autonomy mode

The agent runs without interruption. Powerful for well-defined, low-risk tasks; dangerous for anything touching sensitive code.

Auto-Run set to Run Everything (informally called YOLO mode) auto-accepts all changes and commands. Cloud Agent runs tasks asynchronously in an isolated cloud environment:

Fix all ESLint warnings in src/components/. Run npm run lint
after each fix to verify. Commit each fix separately with a
descriptive message.

Cloud Agent is the safer option for autonomous work: it runs on a clone of your repo, so your local working directory stays untouched until you review and merge. Cursor’s own security guidance says never to use Run Everything, because it skips all safety checks.

Use --dangerously-skip-permissions for batch operations, or enable sandbox mode (/sandbox) for safer autonomy:

claude --dangerously-skip-permissions -p \
  "Fix all ESLint warnings in src/components/. Commit each fix separately."

Sandbox mode is preferred because it provides autonomy within defined boundaries (filesystem and network restrictions) rather than bypassing all safety checks.

For a trusted unattended job, approval_policy=never suppresses prompts but does not expand sandbox access. Always keep the sandbox explicit; if Codex needs to cross its boundary, that action fails instead of prompting:

codex exec --sandbox workspace-write -c approval_policy=never \
  "Fix all ESLint warnings in src/components/. Commit each fix \
   with a descriptive message."

Use this only in a trusted CI identity or a disposable checkout. Codex Cloud tasks run in a separate hosted environment, so local files remain untouched until you apply or merge the resulting diff.

Best for: Lint fixes, formatting, bulk renames, documentation generation, test boilerplate, migration scripts across many files.

Explore first, then execute one step

The mechanics differ per tool; the discipline does not. Start read-only to understand and plan, review that plan as a discrete artifact, and only then switch to execution for one scoped step at a time. Three prompts carry the whole pattern.

The first runs in read-only mode and forces a plan without a single edit:

In read-only/plan mode: map every call site of `processPayment` in `src/`,
list which modules import it, and identify where Stripe idempotency keys are
set. Then produce a refactor plan to make the handler safely idempotent, as a
numbered TODO where each step names the exact files it touches and the tests
that cover it. Do not edit anything yet — output the plan only.

The second runs after you have reviewed that plan. The hard stop at the end is the point: one step, then a report, then your decision.

Execute step 1 of the plan only: add an idempotency key derived from the
request to `processPayment` and pass it to the Stripe `charges.create` call.
Update the 3 call sites you listed. Run `npm test -- payments` and paste the
results. Stop and report before touching step 2 — do not start the next step
until I confirm.

The third closes the loop before you accept the diff. Read-only mode does not make a plan correct; it makes it reviewable, and this is the second line of defense:

Before I accept these edits, review your own diff as a hostile senior reviewer
on a payment path: list every edge case, error path, and concurrency concern
you did NOT handle, and call out anywhere you guessed at business rules instead
of reading them from the code. Be specific about line numbers.

Those three are the production-grade version of the pattern, written for one refactor. The prompt below is the same shape as a reusable session script — three phases in one place, with the mode switch called out between them, for when you are setting up the work rather than executing it:

Phase 1 (Analysis - use ask/plan mode):
Read the payment processing module in src/payments/. Explain the
current architecture and identify the three riskiest areas for
our planned refactoring.

Phase 2 (Planning - stay in ask/plan mode):
Based on your analysis, create a refactoring plan. Save it to
docs/payment-refactor-plan.md. Include risk assessment for each step.

Phase 3 (Implementation - switch to agent/normal mode):
Implement step 1 from the plan. Write tests first, then implement.
Run tests after each change.

A decision framework for picking a mode

Are you trying to understand code, not change it? Use read-only/analysis mode.
Is the task well-defined with clear verification? Use guided execution mode and let the agent work through the task with your periodic review.
Is the task mechanical and low-risk? Consider full autonomy with appropriate isolation (cloud agent, sandbox, cloud thread).
Is the task touching sensitive code? Use guided execution with per-file approval.
Are you unsure? Start with guided execution. You can always loosen permissions mid-session; you cannot un-apply an edit you never saw.

Running two modes at once

Advanced teams use different modes simultaneously across multiple sessions.

Run a Cloud Agent on a lint-fix task (autonomous) while you use the main Agent for feature development (guided). Review the Cloud Agent’s changes when they are ready, without interrupting your feature work.

Run a headless Claude session to fix lint warnings in one terminal tab while working interactively on a feature in another. Use --continue to pick up either session later:

# Terminal 1: Autonomous lint fixes
claude -p "Fix all ESLint warnings in src/. Commit each fix." --allowedTools "Edit,Bash(npm run lint)"

# Terminal 2: Interactive feature development
claude

Launch a cloud thread for the mechanical task and work locally on the feature. Codex runs both in parallel:

Cloud thread: Fix all TypeScript strict mode errors in src/utils/.
Commit each fix with type: "fix(types)" message.

Meanwhile, work on your feature locally in the IDE extension or CLI.

The autonomous half of that split needs its scope written down, because nobody is watching it:

Fix all [ISSUE TYPE] in [DIRECTORY]. For each fix:

1. Make the minimal change needed
2. Run [VERIFICATION COMMAND] to confirm the fix
3. Commit with message: [COMMIT FORMAT]
4. Move to the next instance

Only modify files in [DIRECTORY]. Do not change test files.
Do not install new dependencies. Do not modify configuration files.

Where mode selection goes wrong

The agent runs ahead of an unreviewed plan. Skip the read-only phase and it executes against its own assumptions. Review the plan as a discrete artifact before switching modes.
You stay in analysis mode too long. Thirty minutes of questions consumes the context the implementation needed. Time-box analysis to five or ten minutes, then switch.
You mix modes within a single prompt. “Analyze the auth module, then refactor it” forces an internal mode switch, and the agent usually skips the analysis and jumps to the refactor. Separate them into distinct prompts.
Agent mode edits files you did not intend. A vague prompt in execution mode invites scope creep. Name the files, use checkpoints to roll back, and reject hunks that touch anything off-plan.
The Codex workspace sandbox includes sensitive repo files. workspace-write can edit files such as .env or deploy manifests when they sit inside the workspace, and on-request does not prompt for every such edit. Keep secrets out of the workspace, and stay in read-only until the plan is reviewed on sensitive repositories.
Full autonomy on a task that needed judgment. Autonomy works where “correct” is mechanical and verifiable. API design, error-handling strategy, and performance work all produce better results in guided mode.
You forget to switch back. After an investigation in analysis mode, an agent that seems unresponsive to implementation requests is usually just still in read-only. Check the mode indicator before debugging the prompt.

Where to go next after choosing a mode

Human in the Loop The review gates and supervision habits that pair with mode discipline.

Context Windows How mode choice affects context consumption and session length.

Cost per Context The cost implications of different modes and autonomy levels.

Grill Me and Grill With Docs Ask mode taken to its logical end — the agent interviews you one question at a time until you align.