How to Monitor a Long-Running AI Coding Agent Without Watching the Terminal

You start a coding agent on a big job — a refactor, a data migration, a test-suite green-up — and it's going to run for an hour or three. You don't want to sit and watch the terminal scroll that whole time. You also don't want to walk away blind and come back to find it wedged on a question from forty minutes ago. The middle ground is monitoring: a way to keep tabs on a long run without babysitting it.

The catch is that "monitor a long-running coding agent" means several different things, and the tool that solves one doesn't solve the others. This guide sorts them into layers — passive output, event hooks, push notifications, and escalation-on-decision — and says where each fits. It's agent-agnostic: the same layering works for Claude Code, Codex, or any MCP-based agent.

What "monitor" actually means here

Three different jobs hide inside that one word:

• Look when you want to. Passive observability — the run's output is there if you go and check it. Nothing interrupts you.
• Be told when something happens. Active alerting — a completion, a failure, or a wait-state pushes a signal to you.
• Be pulled back when it needs a decision. Escalation — the agent is blocked and can't proceed until a human answers.

Most "monitoring" advice only covers the first. A long unattended run needs all three, because the expensive failure mode isn't missing a log line — it's the agent sitting idle on a decision while you're none the wiser.

Layer 1: Logs and live output (passive, always on)

The zero-setup layer is the output the agent already produces. Keep the run in a persistent terminal session so you can reattach from anywhere:

tmux new -s agent      # start the run inside; detach with Ctrl-b d
tmux attach -t agent   # reattach later, from another shell or over SSH

screen behaves the same way. Redirect to a file if you'd rather tail -f run.log than reattach. Most agents also keep a session transcript or history you can page through after the fact.

Passive output is universal — it's just stdout. It's the right tool for spot checks and post-mortems: "is it still going?", "what did it do at step 12?" What it can't do is get your attention: you have to remember to look, the exact habit you're trying to escape.

Layer 2: Event hooks (turn moments into signals)

The next layer reacts to specific moments instead of making you poll. Claude Code exposes lifecycle hooks — notably a Stop hook when a turn ends and a Notification hook when it's waiting on you — that run any shell command you point them at. Other agents vary; where one has no hooks, wrap its process and fire on exit, or watch the log for a marker line.

A hook is where monitoring stops being passive: the moment the agent stops or starts waiting, something runs — a desktop banner, a log line, a webhook. The step-by-step wiring has its own guide:

→ Using the Claude Code Stop hook to trigger a real notification

The limit of a hook by itself is that it fires locally: osascript or notify-send drops a banner on the machine you walked away from. Useful at your desk; invisible once you leave.

Layer 3: Push notifications (get the signal off the machine)

Point the hook command at a push service and the signal follows you off your desk. A one-line curl to ntfy.sh (open-source, free), Pushover (one-time paid), or a Slack / Telegram webhook lands the alert on your phone:

curl -s -d "Agent finished" ntfy.sh/your-topic

This is the right monitoring layer for "just tell me when it's done or broken." Completion and failure are FYIs — one-way is exactly enough.

The ceiling is that a push is one-way. It can tell you the agent is blocked; it can't carry your answer back. For a decision, you're notified of a problem you still have to walk back to solve — and the agent stays idle the whole time.

Layer 4: Escalation on a decision (when monitoring isn't enough)

The last layer is for the one case the others can't close: the agent hits a decision, an approval, or a destructive command it won't run alone, and every minute you don't answer is wasted. You don't want a louder alert — you want to resolve it.

That's AgentCall. It's a pure-MCP voice bridge: when the agent needs a human, your phone rings, it explains what it's stuck on in its own words, you talk it through, and it keeps working. The words you speak become the tool result it was blocked on — no returning to the terminal to type anything.

Because it's an MCP server, it isn't Claude-Code-only. Claude Code is the tested client; Codex CLI works in beta; any other MCP client that allows long-running tool calls should work but is untested. A few things that fit the monitoring job specifically:

• No AI in the middle. AgentCall never generates words your agent didn't say — your speech becomes text for the agent, the agent's text becomes speech for you.
• You set what's worth a ring. Standing rules in plain language decide which events escalate — irreversible actions, approvals, completion, failures — so it isn't noise.
• Mishearing can't cause damage. Transcription is treated as untrusted, so the agent confirms destructive instructions out loud before acting.
• Miss it and nothing breaks. No answer within a few minutes and the agent is told the call went unanswered and proceeds on its best judgment; the missed call is in your History, with optional voicemail.

Connecting is one command:

claude mcp add --transport http --scope user agentcall https://agentcall.io/api/mcp

Sign in with Google, add AgentCall to your phone's home screen (a PWA — there's no app to install) so it can ring you, and place a test call from the Quickstart. Free in beta, speech minutes included.

Name check: this is AgentCall.io, voice escalation for coding agents — not agentcall.co, an unrelated programmable SMS/voice API for building telephony into your own app. Different product, different job.

Layering it for a real unattended run

You don't choose one layer; you stack them by the cost of missing the event:

1. Logs in a tmux session — always on, for spot checks and post-mortems.
2. A hook to a push for "finished" and "failed" — cheap one-way FYIs.
3. A ringing phone for "blocked on a decision" — because idle-agent time is the real cost, and only a two-way channel ends it.

Set the standing rules once and a three-hour run stops being something you sit and watch. For the fuller playbook on walking away entirely, see running coding agents unattended overnight, or start from the AgentCall home page.

Next: Connect AgentCall in one command → · Run coding agents unattended overnight →