Why AI Coding Agents Still Need Human Intervention

An autonomous coding agent will keep working for hours — and then stop to ask you one question. Here is why agents pause, what they are waiting on, and how to stay useful without staring at the terminal.

A coding agent runs for an hour, makes progress on a refactor, and then stops. The terminal shows a question the agent cannot answer alone. The developer, who is no longer at the desk, finds out five minutes later — or five hours later — that the agent has been waiting on a single y/n permission prompt the whole time. The agent is not broken. The loop is. The developer has been polling, the agent has been idle, and the work has been sitting in the gap between them.

That gap is the subject of this article. The question behind every search for "coding agent waiting for input", "AI coding agent stopped", "coding agent needs permission", and "Claude Code waiting for input" is the same: why does an autonomous coding agent stop and wait, and how do you intervene without watching it run?

An autonomous coding agent still has moments where it needs you

Even the most capable local coding agent — Claude Code, Codex, OpenCode, Pi, and the rest — runs for a long stretch and then stops to ask for a human. The pauses are not random and they are not a sign of model failure. They are the moments the agent reaches a boundary it cannot cross alone.

The classes of pause that show up in real workflows:

• Permission. A shell command, a file write, a network call, an install script. The agent has the intent; it does not have the trust.
• Missing decision. "Which JSON shape do you want?" "Serial or parallel?" "Which deploy environment for this branch?" The agent can enumerate the options; it cannot pick between them.
• Clarification. A line in the spec that reads two ways. A requirement that contradicts a previous one. The agent can detect the ambiguity; it cannot resolve it.
• Ambiguous requirement. A phrase that the agent could implement four different ways, all defensible. It needs to know which one the developer actually meant.
• Failed test or tool call. A test broke. A dependency is missing. A tool returned an error the agent cannot recover from without context.
• Blocked environment. The workstation lost network. The container died. The credentials expired. The agent can describe the block; it cannot unblock it.

Every one of these pauses has the same shape: the agent has done what it can, and it needs one piece of information or one approval that only a human can supply. The agent does not stop because it is confused. It stops because it has hit a boundary, and the boundary is not the model's — it is the developer's.

Why coding agents stop instead of continuing

The pause looks the same from the terminal: an idle prompt, a blinking cursor, the agent's waiting indicator lit. The reason underneath the pause is not the same, and the response the agent needs is not the same. Treating every pause as "agent is stuck" hides the actual shape of the problem.

Permission and safety boundaries

The most common pause. The agent has decided to run a tool call it is not allowed to run without confirmation — a shell command that touches the filesystem outside the project, a network request to a third-party API, an install of a system package, a write to a config file the developer has marked sensitive. The pause is a deliberate safety boundary, and it exists for a reason: an autonomous agent that can do anything without asking is one prompt-injection away from doing anything without asking. Permission prompts are the cost of letting the agent run with real tools in a real environment.

Questions and missing context

The agent has reached a decision point where the spec, the codebase, and the conversation history do not uniquely determine the right answer. Two designs are equally defensible; the spec uses a word that could mean two things; the deploy environment is not encoded anywhere the agent can read. The agent pauses to ask because the alternative is to guess and produce something the developer will undo.

Errors and failed tool calls

A test broke and the agent does not know whether the test was already broken or whether its change broke it. A package install failed and the agent cannot tell whether the failure is transient or systemic. A tool returned an error string the agent does not recognise. The agent pauses to ask whether to retry, revert, or change direction — because continuing blind means risking more failed tool calls on top of an unknown baseline.

Ambiguous decisions

A migration has two valid end schemas. A refactor can land in three different shapes. A test suite can be split per-package or per-feature. The agent can pick any of them; it cannot know which one the developer will accept without asking. The pause is the agent explicitly refusing to make a decision it has no basis for.

Task completion and next-step decisions

The agent has finished the task it was given, and there is no obvious next task. It could stop. It could keep going on adjacent work that is not in the brief. It could ask. The pause is the agent choosing to surface the "what now?" decision instead of either silently stopping or silently expanding scope.

Every one of these pauses is correct behaviour. The pause is not the bug. The problem lives elsewhere.

The real problem is not that agents ask questions

The reflex, when a coding agent pauses, is to think the pause is the problem. It is not. An agent that asks before doing something dangerous is doing its job. An agent that surfaces ambiguity instead of guessing is doing its job. An agent that flags an unrecognised error instead of pretending it understood is doing its job.

The problem is what the developer has to do to learn that the agent has paused.

If the developer is sitting at the terminal, the problem barely exists. The terminal lights up; the developer reads; the developer types y; the agent moves on. The loop is local, fast, and observable.

If the developer has left the desk, the problem is the loop, not the pause. The developer is somewhere else. The agent is somewhere else. The pause is invisible until the developer walks back or refreshes a view. The developer's attention, instead of being spent on decisions, is being spent on checking whether the agent is still alive. That is the babysitting problem: not the agent asking, but the human having to watch to find out it asked.

This reframing matters because the fix is not "make the agent never ask". That fix is unfixable — and would be unsafe if it were. The fix is to change what the developer does between pauses: stop polling for the pause, and let the pause come to the developer.

The human-agent loop

Every persistent coding-agent workflow runs the same loop. The names of the steps vary; the shape does not.

OBSERVE
  ↓
RESPOND
  ↓
DIRECT
  ↓
CONTINUE
  ↓
Agent works
  └────────→ OBSERVE

• OBSERVE. What is happening right now? Which session, which project, which agent, which task, which tool call was last, and what is it waiting on? The developer should be able to look once and see the state.
• RESPOND. If the agent is asking a question or requesting permission, the surface has to let the developer answer or approve without leaving it. Both directions — answer a clarifying question, approve or reject a permission prompt — are part of RESPOND.
• DIRECT. Stop, steer, or change context. The agent queue accepts the redirect; the developer does not have to be at the terminal to issue it. Stop is the abort path. Steer is the course-correct path. Change context is the "this is no longer the priority" path.
• CONTINUE. The agent resumes work on the same session, with the same context, on the same machine. The conversation, the working directory, and the agent process all survive the developer's absence. Returning hours later means opening the same surface and finding the same work, not starting a new session.

The loop is closed when each of those four jobs is reachable from the developer's current location. It is broken when any one of them is not — when RESPOND requires walking back to the terminal, or DIRECT requires killing the process, or CONTINUE requires starting over.

Every architecture that calls itself a "remote coding agent workflow" is graded on how much of this loop it covers from outside the host. The architectures that only cover OBSERVE — that give the developer a view but not a way to respond — will look fine until the first permission prompt, and then the developer will walk back to the laptop anyway.

Notifications change the workflow

The cheapest change to the loop is also the most underestimated.

Polling
"I should check again."

vs

Proactive
"Tell me when you need me."

Polling is what the developer does when nothing else exists. The developer has a coding agent running, the developer cannot see the terminal, so the developer reloads the terminal multiplexer, opens a status page, or asks a colleague. Every reload is a context switch from whatever the developer was actually doing. If the agent has not paused, the reload was wasted. If it has paused, the developer still has to walk back into the loop to respond.

Proactive notification inverts the cost. The agent's state — running, waiting for input, waiting for permission, idle, finished — is surfaced to the developer at the moment it changes, on whatever device the developer is already looking at. The developer does not decide when to check; the developer decides what to do when the check arrives. If the agent is still running, the developer sees a heartbeat and continues the actual work. If the agent is waiting, the developer sees the question, answers it from wherever they are, and the agent moves on.

The shift from polling to proactive is not a UI preference. It is what makes a long-running agent compatible with a developer who is not sitting in front of it. A passive status page that the developer has to remember to open is still polling, just with a nicer frame. A notification that lights up the developer's phone when the agent needs them is the first time the developer is no longer the polling loop's bottleneck.

What should you do when an agent needs you?

The five things the developer actually does at the moment the agent pauses. Each one is a separate verb in the loop, and each one benefits from a different mechanism.

Answer the question

The agent has surfaced a clarifying question. The developer replies in plain text. The agent incorporates the answer and continues. The minimum useful surface: a text input that routes back to the same session, with the question visible alongside the answer so the developer does not lose context.

Approve the action

The agent has surfaced a permission prompt. The developer glances at the tool call — what command, what file, what network destination — and says yes or no. One-tap approve or deny on a phone; a structured card on a desktop; never a "type y and press enter" prompt, which forces the developer into a terminal-shaped interaction on a five-inch screen.

Steer the task

The agent is going the wrong way. The developer issues a redirect — "use the existing parser, no new dependency" — and the agent incorporates the steering and continues on the new path without needing to be restarted or re-prompted. Steering is the verb that distinguishes "the agent is mid-task and you want to redirect it" from "the agent finished and you want to give it a new task".

Stop the task

The agent is doing something the developer does not want done at all. The developer aborts. The agent stops cleanly, the session state is preserved (so the developer can inspect what was done), and the agent is ready for a new directive. Stop is not kill — it is "end this task, save the work, await the next one".

Continue after returning later

The developer has been away for hours. They open the surface, find the same session, see what the agent is doing or has been waiting on, and either resume the same task or hand it a new one. CONTINUE is the verb that proves the loop survived the developer's absence. If CONTINUE means "start a new session and re-prompt from scratch", the loop did not survive.

The five verbs map cleanly onto the four jobs of the loop: OBSERVE is the surface that makes the verbs reachable; RESPOND covers Answer and Approve; DIRECT covers Steer and Stop; CONTINUE covers the return-later case.

Why "without babysitting" does not mean "without humans"

The category framing behind the persistent-agent workflow — Coding agents without babysitting — is sometimes read as "agents that run without humans". That is not what the framing means, and any product that promises it is overselling.

The framing removes unnecessary waiting and checking. The human stays in the loop. The human is the source of permission, the source of clarification, the source of steering, and the source of "stop". What the framing removes is the developer's role as a polling mechanism — the developer's role of repeatedly checking whether the agent has paused so they can respond. The human does not go away. The babysitting goes away.

Two consequences follow from this distinction:

• An agent that truly runs without human input is not "without babysitting". It is "fully autonomous". That is a different product class with different safety properties. Treating them as the same thing makes the autonomous one look safer than it is, and the supervised one look more annoying than it has to be.
• An agent that is "without humans" does not need this article. The audience for the human-intervention question is the audience that has decided the human stays in the loop. The question for that audience is not "do I need humans", it is "how do I make the human-in-the-loop loop pleasant".

NightMe's design starts from that premise. The human is not removed; the polling around the human is removed.

How different tools handle human intervention

Different control surfaces cover the human-in-the-loop verbs to different depths. None of them is universally best. The trade-offs that matter are coverage of the five verbs and the cost of keeping the loop closed across an absence.

• Terminal-first. SSH into the workstation and drive the agent at the terminal. Coverage of every verb is total — the terminal is the agent's native surface — but the developer's hands have to be at a keyboard, and the developer has to be polling to know when to come back.
• Vendor-native mobile / web control. Anthropic's Claude Code ships Remote Control, OpenAI publishes a Codex "from anywhere" flow, and GitHub Mobile shipped live notifications for coding-agent sessions. These cover the verbs inside the vendor's surface — tool-call cards, structured approvals, push notifications — and tie the loop to one vendor.
• Notification-driven systems. Push-based status: progress, waiting-for-input, idle, finished. The state changes reach the developer; the verbs that fit (Answer, Approve, Stop) are reachable from the notification. The trade-off is depth — a notification surface is excellent for "the agent needs you" and less excellent for "show me the diff".
• Chat-based control. The developer's existing chat app becomes the control surface, with a small bridge on the workstation forwarding messages to and from the agent. The verbs reach the developer inside an app the developer already uses, with the developer already familiar with the reply pattern, the threading, and the notifications. The trade-off is that chat is a medium, not a tool-aware UI — vendor-specific tricks may not survive the round trip.
• Dedicated mobile apps / bridges. Companion apps designed for the agent loop, not for shells generally. Tool-call cards, structured approvals, and progress are first-class. Setup usually means installing two things, and the bridge has to stay paired.

A useful single-test for any of these: does the surface let the developer Answer, Approve, Steer, Stop, and Continue without leaving it? If any verb requires walking back to the terminal, the loop is not closed for that verb.

Where NightMe fits

NightMe is a chat-based control layer for local coding agents. What that means in practice for the human-intervention loop:

• The agent keeps working locally. The source tree, the tools, the MCP servers, and the credentials all stay on the workstation. The agent process is the same one the developer would have started by hand. The agent does not move to the cloud; the developer's reply moves to the agent.
• Status is proactively surfaced. When the agent changes state — running, waiting for input, waiting for permission, idle, finished — the change reaches the developer in the chat, on the device the developer already has open. The developer does not poll; the developer is told.
• The human replies through chat. Answer, Approve, Steer, Stop — all five verbs are reachable as chat messages or chat-app-native reactions. There is no new mobile app to install; the chat app the developer already uses is the surface.
• Stop / steer / continue remain explicit human controls. NightMe does not remove the human's role as the source of permission, clarification, and redirect. It removes the developer's role as the polling mechanism around that role. Stop is an explicit verb the developer issues; the agent does not infer it from silence.
• Session context remains available. The same session — same conversation, same context, same working directory — is the one the developer returns to. Continuing after an absence means opening the same chat thread, not starting a new session.

This is one implementation of the "without babysitting" framing, not the only valid one. The framework that any control surface is graded against — does it cover the five verbs from outside the host, does it surface the state without polling, does it preserve the session across an absence — is the subject of How to control AI coding agents from anywhere and of How to run AI coding agents from your phone. The agent-specific walkthrough — what changes when the agent in the loop is Claude Code — lives in Run Claude Code from your phone.

What good agent supervision looks like

The definition that falls out of the loop above:

The developer should spend their attention on decisions, not on checking whether the agent is still alive.

If the developer is checking, the supervision is broken — the developer is acting as a polling loop on top of the agent loop, and the cost is context switches out of whatever the developer was actually doing.

A supervision workflow that works has three properties:

• State reaches the developer, not the other way around. Proactive notification when the agent pauses; heartbeat or progress signal when the agent is still working. The developer decides what to do when the check arrives; the developer does not decide when to check.
• Every verb in the loop is reachable from the developer's current surface. Answer, Approve, Steer, Stop, Continue. If any verb forces a walk back to the terminal, that verb is the bottleneck of the workflow.
• Sessions survive the developer's absence. The same conversation, the same context, the same machine. Returning hours later means opening the same surface and finding the same work.

Once those three properties are true, the developer spends attention on the things only a developer can do — choosing between designs, approving consequential actions, redirecting the agent when it goes the wrong way — and the rest of the loop closes itself.

What's next

• When your coding agent needs you — internal page planned; link will be added when published. The interruption layer in depth: every verb in the loop, every state the agent can be in, and what to do at each one.
• How to control AI coding agents from anywhere — the architecture-level walkthrough of the human-in-the-loop loop: what must survive the developer's absence, and which control surfaces cover which verbs.
• How to run AI coding agents from your phone — vendor-neutral five-architecture deep-dive, full trade-off table, security section.
• Coding agents without babysitting — the category framing behind the persistent, supervised coding-agent workflow.

When your coding agent needs you — internal page planned; link will be added when published. Remote / continue coding agents — internal page planned; link will be added when published.

Last updated: 2026-09-18 — verified against code.claude.com/docs/en/remote-control, openai.com/index/work-with-codex-from-anywhere/, and the GitHub Mobile Live Notifications changelog. Vendor features in this row change quickly; verify before relying on a specific cell.