How to Make Coding Agents More Autonomous With Fewer Interventions

A coding agent hands control back to you for one of four reasons: a tool call needs your approval, it needs an answer the repository never gives, it repeats a mistake you already corrected, or its workspace won't run. A wider permission mode fixes only the first. Sort a week of stops into those four kinds, then fix the causes in order, starting with the workspace every other fix depends on.

Four reasons an agent hands control back to you

Label each stop from the transcript by what the agent was doing just before it stopped and what the person supplied to get it moving.

Approval gates. The runtime paused a tool call for permission. Some are routine, such as a test run or a dependency install. Others guard something you want guarded, such as a push or a production deploy.

Clarification stops. The agent asked a question before writing anything, such as "Which billing path should I change?" The repository could have stated the answer, or only the requester could decide it.

Correction loops. The agent produced work and a person sent it back, as in "Use the existing retry helper" after a diff. The missing context surfaced only after the agent acted on a wrong assumption.

Environment stalls. A dependency failed to install, a fixture was missing, or a check could not run, so the agent asked you to repair the setup.

Count a week of stops before you change any setting

Pull a week of sessions from the repository where agents struggle. Our guide to analyzing Claude Code and Codex session logs covers where those transcripts live and what to redact.

For each intervention, record the category, the trigger, and what the person did. Read the reply before you settle on a label: an agent can report a failing test when the real problem was an undocumented setup command. Tally the categories, look for triggers that repeat, and split approval gates into routine prompts and gates you intend to keep. If most stops are environment stalls, permission work can wait.

Fix environment stalls first

An agent verifies its work by running the checks a developer runs. A clear test failure gives it a next action. A service that never started gives it nothing, so it stops and asks you.

Run the build, test, and lint commands yourself on a clean checkout in the agent's environment. Make every step that depends on a developer's machine, such as a pinned tool version, a local secret, a running database, or a one-off fixture, reproducible or written down. Give the agent a fast, targeted check to run while editing and keep the full suite for before the change is accepted. Fix flaky tests too, since a failure on unchanged code leaves the agent unable to tell whether its edit caused it.

Fix clarification stops with instructions the agent loads

Working commands, conventions the agent cannot infer from the code, and rules about generated files belong in the instruction file your agents read at startup. Check which file each agent loads. Cursor reads AGENTS.md in the project root and subdirectories. Codex takes at most one file per directory from the project root down, preferring AGENTS.override.md, up to 32 KiB by default. Claude Code reads CLAUDE.md, and from v2.1.277 reads AGENTS.md only when no CLAUDE.md or CLAUDE.local.md is present. Our comparison of AGENTS.md, CLAUDE.md, and Cursor rules shows how to keep one copy for all three.

Keep the root file short. Claude Code's documentation suggests under 200 lines per CLAUDE.md, since longer files reduce adherence. Before adding a rule, ask whether a test, lint rule, or hook could enforce it instead, and move long, task-specific procedures into a skill, which Claude Code and Codex load only when it is used. Keep the file current, because a test command that no longer exists sends the agent down a dead end and back to you, which is why a stale instruction file is worse than a missing one.

Turn a repeated correction into a written rule

A correction typed into chat is not guaranteed to reach the next session or another teammate. Some agents save corrections automatically, but check what was saved before relying on it. If your tally shows the same correction twice, put it in a file the agent reads next time, written as an action it can check. "Do not edit generated files" is a start. "After changing api/schema.yaml, run pnpm generate:client and commit its output, and never edit files under src/generated/ by hand" names the trigger, the command, and the boundary.

Verify the rule against the code before you commit it, then confirm a fresh session follows it. Where a check can enforce the rule, such as a CI step that fails when the generated client is out of date, prefer the check, since it catches the mistake whether or not the agent read the instructions.

Narrow the task so the agent can verify it

"Fix checkout errors" leaves the agent to choose which error, which behavior, and which files are in bounds, so it asks you or makes a change you reject. A task the agent can finish alone states the expected behavior, the check that proves it, and what is out of scope.

Update checkout validation so an expired coupon returns the existing invalid-coupon error. Add a test for that case and run the checkout test suite. Do not change coupon storage or the public API.

If you cannot write the done criterion, the task is not ready for an unattended run.

Move routine approvals into committed rules

Once the other three categories are under control, write a narrow rule for each routine command your team considers safe and commit it, so every engineer's agent gets the same rule. These details come from each vendor's documentation as of November 3, 2026.

Claude Code uses allow, ask, and deny rules under permissions, written as patterns such as Bash(npm run *) and evaluated deny first, then ask, then allow. "Yes, and don't ask again" saves a rule to .claude/settings.local.json on one machine, so put agreed rules in the shared .claude/settings.json. Its optional sandbox, enabled with /sandbox, can auto-approve sandboxed Bash commands. Deny rules and content-scoped ask rules still apply, but auto-allow bypasses whole-tool Bash ask rules outside plan mode.

Codex pairs a sandbox mode with an approval policy. Its Auto preset lets it edit and run commands in the working directory without asking, and asks before it leaves the workspace or uses the network. Project-local .rules files under .codex/rules/ hold prefix_rule entries that set allow, prompt, or forbidden for specific commands, and the most restrictive match wins. Project-local rules load only when the project's .codex/ layer is trusted. Restart Codex after adding a rule, then verify its match before relying on it.

Cursor sets behavior through Run Modes. Auto-review runs allowlisted calls, sandboxes shell commands where it can, and sends the rest to a classifier. A committed .cursor/permissions.json carries allow and block instructions for Auto-review, and .cursor/sandbox.json controls what sandboxed commands can reach.

Classifier-based modes reduce prompts by judging each action, but Cursor's documentation states that Auto-review is not a security boundary. For the gates below, use a deterministic rule as well.

What should stay a human decision

Some actions should pause an agent every time. The agent can prepare the change and run local checks, then wait for a person:

• Production deploys
• Schema and data migrations against a shared database
• Access to secrets or broader credentials
• Force-pushes, history rewrites, and deleting shared branches
• Changes to security-sensitive dependencies, such as an authentication library

Encode these as rules rather than habit. In Claude Code, a matching deny rule blocks a call even when a PreToolUse hook returned allow, and setting permissions.disableBypassPermissionsMode to "disable" in managed settings stops anyone from switching to bypass mode. In Codex, a prefix_rule with prompt or forbidden holds the line for commands that leave the sandbox. Command rules do not stop an agent from editing package.json or a migration file inside the workspace, so back the dependency and migration gates with a required CI check or code-owner review. When these are the only approvals left in a week of transcripts, each prompt carries a decision worth a person's attention.

FAQ

Should we run agents in a full-bypass mode inside a container?

Every tool offers one, and Codex labels its full-access mode "not recommended". If you use one, run it in an environment with no production credentials and no push access to shared branches, and fix the four categories first so bypass does not hide them.

How many interventions per session is normal?

We do not know of a published benchmark that would transfer to your repository. Use your own tally as the baseline and re-run it on comparable tasks after each fix. Our guide to coding agent metrics covers how to count corrective turns.

Start with the corrections you keep repeating

Run the one-week tally, then take the correction loops from it. For each correction that appears more than once, verify the right answer against the code, write it as a rule with its trigger and its check, and confirm a fresh session follows it.

Corrections that live in one engineer's chat history reach only that engineer's agent. To share them across the team, create a Library and connect the repository to Dosu, then configure your agent with npx @dosu/cli setup. Record a verified correction with the Dosu MCP server's write_knowledge tool and confirm that the write is anchored to the connected repository and branch. A teammate with access to that Library can then call read_knowledge for the same repository and branch, find the note in the index, and fetch its full content with note_id before applying it. Count that correction loop again next week.