The short version: In a single week, Claude Code, Cursor, and Cline each changed how you supervise the sub-agents their main agent spawns — and they picked three genuinely different answers. Claude Code makes a background sub-agent ask you (an interactive permission prompt). Cursor lets your code intercept it (programmatic hooks). Cline makes you set a mode first (plan can't edit; act can). If you run agents that spin up other agents, the control model — not the model quality — is now the thing to choose on. Here's the one-axis, three-answers map.
The question underneath all three changes is the same: when your agent spawns a sub-agent that goes off-script, what stops it before it touches your repo or your cloud? A year ago most coding agents answered "nothing, really" — a sub-agent inherited the parent's permissions and ran. In July 2026 that stopped being acceptable, and the three leading tools shipped fixes within days of each other. They just don't agree on the shape of the fix.
Claude Code: the sub-agent asks you#
Before July, Claude Code's background sub-agents had a blunt behavior: a tool call that needed permission was auto-denied if it happened outside your interactive session, which quietly broke legitimate work and taught people to over-grant up front. v2.1.203 (July 7) changed that: a background sub-agent's permission request now surfaces in your main session, the dialog names which agent is asking, and pressing Esc denies just that one tool rather than killing the run.
Two adjacent fixes show the same instinct hardening. v2.1.200 (July 3) stopped AskUserQuestion dialogs from auto-continuing by default — the human answer is required, not assumed. And v2.1.207 (July 11) fixed a real hole: non-interactive runs (claude -p, the SDK) were being permanently recorded as consented without ever showing the security consent dialog. That last one matters most for anyone running Claude Code headless in automation — a silent-consent bug is exactly the failure that turns an agent into a liability.
The design bet: the right place to stop a sub-agent is a human, live, told exactly which agent wants what.
That bet is great when a person is there. It's the wrong tool when no one is — which is Cursor's opening.
Cursor 3.11: your code intercepts the sub-agent#
Cursor 3.11 (July 10) went the opposite direction. Instead of a prompt, it added programmatic lifecycle hooks for cloud agents: beforeSubmitPrompt, subagentStart (and subagentStop), afterAgentResponse, afterAgentThought, preCompact, and stop, on top of existing tool/file hooks like preToolUse, beforeShellExecution, and afterFileEdit (Cursor docs — Hooks). These let your own code "observe and control the agent conversation itself: prompts, responses, thinking, sub-agents, compaction, and turn completion" — and, notably, build self-correcting loops.
The difference from Claude Code is the difference between a bouncer and a firewall rule. A subagentStart hook can inspect what a sub-agent is about to do and block, rewrite, or log it without a human in the loop — which is the only model that works when agents run in CI, on a schedule, or across a fleet. It's more work to set up (you write the policy), and it's less safe by default (a missing hook is an open door), but it's the model that scales past one supervised developer.
Cline: you pick the mode, the agent lives inside it#
Cline's answer predates this week but got sharpened in it. Its plan/act mode is a human-toggled gate: plan mode reads the codebase and proposes a plan but can't edit files; act mode unlocks the full edit-and-shell toolset. It's the simplest mental model of the three — a two-position switch you control — and it maps cleanly onto how careful developers already work: understand first, change second.
The July releases fixed the seams. v3.0.36 (July 3) made switching to act take effect immediately — ending the plan-mode run and continuing with the approved plan on the full toolset, instead of the model limping along with plan-mode tools and trying to edit files through shell commands. v3.0.37 (July 4) made mode switches visible to the model so it knows the rules changed mid-session, and v3.0.38 (July 7) gave plan and act distinct accent colors so you can see which gate you're in at a glance. It's the least programmable model and the hardest to misuse — a good fit for a solo builder who wants a guaranteed read-only phase before anything touches disk.
So which one#
Pick by who is watching when the sub-agent runs:
- A human is supervising, interactively → Claude Code. The per-action prompt is the least surprising and now names the agent asking.
- No human is in the loop — CI, cron, a fleet → Cursor. Only programmatic hooks can enforce policy when there's no one to click "deny," and the self-correcting-loop pattern is built for exactly this.
- A solo developer who wants a hard read-only phase → Cline. Plan/act is the simplest gate that guarantees nothing gets edited until you say so.
This is the same axis the whole field is converging on — tool approval has quietly become a framework default, and the interesting question is no longer whether to gate an agent but where the decision lives: in a human's hands, in your code, or in a mode. For a deeper cut on the human-approval patterns underneath these tools, see our walkthrough of human-in-the-loop tool approval across LangGraph, Vercel, and OpenAI. The tools disagree on the answer — but they finally agree on the question.
