[BUG] + [RFC] Tasks run forever: 7-layer architectural root cause + permanent fix proposal (PALMS)

Preflight Checklist

• [x] I am using the latest version of Claude Code

What's Wrong?

I noticed a serious issue while using AI agents, and this is not just a small edge case. It appears across multiple AI tools, not only one. _When an agent starts a long-running subprocess like cargo build, npm run build, Get-ChildItem, or a large find command, the subprocess may finish correctly, but the agent does not reliably recognize that it is done.

Instead, the agent often keeps going, starts new timers, runs extra discovery commands, and ends up looping even though the original task has already completed. This burns tokens, wastes time, and blocks the workflow._

This feels like a major reliability bug for any company building automated AI agents, because the system is acting as if the task is still active even after the real work has already finished.

The issue does not seem to be just a prompt problem. It looks more like a deeper orchestration and process-tracking failure across several layers:

OS process I/O handling

The shell or PTY can remain alive after the child process exits, and the agent may not get a clean signal that the command has finished.

Exit detection is indirect

The agent is often reading text output instead of relying on a true OS-level completion signal, so task completion is inferred rather than confirmed.

Context window drift

Long builds and noisy output can push the original task context out of focus, causing the agent to re-orient and re-check unnecessarily.

Weak task state management

There is no strong lifecycle like PENDING → RUNNING → DONE, so the agent can lose track of what has already completed.

Watchdog loop behavior

A timer fires, the task appears incomplete, another check is triggered, and the cycle repeats.
Subagent coordination issues
Completion is often communicated in text, so the orchestrator may not reliably treat the task as finished.

LLM temporal blindness

The model does not truly track time or process state the way a real runtime does, so it can keep asking for verification even after success.

The important part is that none of these layers alone is necessarily the full cause. The bug seems to happen when they combine, which makes it especially dangerous in large or long-running tasks.

This should be treated as a real product issue, not just a prompt-tuning issue. For agents to be dependable in production, they need stronger process completion detection, better lifecycle tracking, and a more reliable stop condition once the underlying task is actually complete.

What Should Happen?

[FIX]: PALMS (Process-Aware Lifecycle Management System)

A clean way to solve this is to move completion tracking outside the model itself.

PALMS would be an external MCP-compatible daemon that sits between the agent and the operating system. It would require no LLM changes and no framework changes, and could be used as a drop-in layer.

Core idea: structured exit contract

Instead of the agent guessing whether something is finished from text output, the agent should define what “done” means before the task starts.

Example:

{
  "task_id": "build-001",
  "command": ["cargo", "build", "--release"],
  "exit_criteria": {
    "success_exit_codes": [0],
    "success_pattern": "Finished .* target",
    "max_duration_ms": 600000,
    "kill_on_timeout": true
  },
  "output_policy": {
    "stream_to_agent": false,
    "summary_last_n_lines": 20
  }
}

PALMS would then:
spawn the process,
read the real OS exit code instead of inferring completion from text,
kill the full process group when the task completes or is cancelled,
condense large output into a small summary,
and emit exactly one structured completion event.

Example completion event:

{
  "task_id": "build-001",
  "status": "SUCCESS",
  "exit_code": 0,
  "duration_ms": 43218,
  "summary": "Build completed. 0 errors. 3 warnings."
}

The agent should call spawn_task once and receive one completion event once. No polling. No repeated timers. No guessing.

What this would eliminate
PTY / pipe confusion: use process.Wait() and kill the full process group, not just the PID
Exit code guessing: read the exit code directly instead of inferring completion from logs
Context flooding: cap output sent to the agent to a small summary
Weak lifecycle handling: maintain a deterministic PENDING → RUNNING → DONE → FAILED state model
Watchdog loops: remove the need for repeated polling entirely
Text-based completion guessing: replace it with structured JSON completion
LLM re-verification chains: reduce the chance of the model continuing to “check” after the task is already finished
Reproduction examples
Windows / PowerShell

Prompt the agent to list files in a large system directory using Get-ChildItem.

Expected failure mode: the command completes, but the agent starts re-checking, spawns another monitoring pass, and continues looping.

Linux / macOS

Prompt the agent to run a large build such as cargo build.

Expected failure mode: the build finishes, but the agent runs extra commands like find, ls, or ps to verify completion, then repeats the cycle.

Node.js project

Prompt the agent to run npm run build.

Expected failure mode: once the build completes, the agent starts checking for output folders, reruns inspection commands, and may continue looping.

Immediate workarounds until a proper fix exists

1. Wrapper script

Use a wrapper around long-running commands so completion is explicit and structured.

1. PowerShell completion marker

Have commands print a clear done marker after finishing.

1. AGENTS.md circuit breaker

Add rules such as:

do not stream large command output into context,
only read the exit code after completion,
do not run follow-up verification commands after a successful exit,
limit the number of monitoring commands per task.
Ask to platform and MCP teams

I think this should be handled at the agent runtime level and standardized more broadly.

The key requests are:

bind async task completion to OS exit codes, not log parsing,
kill process groups, not just individual PIDs,
add a maximum output-to-context limit for long-running tasks,
standardize a structured task completion event in the task schema.

A minimal event schema could look like this:

{
  "task_id": "string",
  "state": "PENDING|RUNNING|DONE|FAILED|KILLED",
  "exit_code": "int",
  "duration_ms": "int",
  "summary": "string"
}

**This is not a niche bug. It affects any AI agent that manages long-running subprocesses through weak completion detection. A real fix needs stronger process lifecycle management at the system level. It's the most minimalistic fixes as for long term any kind of AI companies should think of these problem it might become problematic for Ai-Agents.

Bug + RFC- Long-Running Tasks Monitoring Issue.pdf

**

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

1. Open an AI coding agent or CLI-based agent capable of executing shell commands.

1. Use a project that contains enough files, dependencies, or build steps to ensure the command runs for a noticeable amount of time (typically 30+ seconds).

1. Ask the agent to execute a long-running command such as:

Rust

cargo build

Node.js

npm run build

Windows PowerShell

Get-ChildItem C:\Windows\System32

1. Wait for the command to complete successfully.

1. Observe the agent's behavior after completion.

Expected Behavior

• The agent detects that the subprocess has completed.
• The task transitions into a completed state.
• Monitoring timers and watchers are cleaned up.
• No additional verification or discovery commands are executed unless explicitly requested.
• The agent reports task completion to the user and stops.

Actual Behavior

• The original command completes successfully.
• The agent continues monitoring the task.
• Additional verification commands may be executed (e.g., ls, find, Get-ChildItem, ps, directory checks, output checks).
• New timers or monitoring loops may be created.
• In some cases, the workflow can continue indefinitely despite the original task already being finished.

Minimal Reproduction Example

Prompt:

Run cargo build and tell me when it is finished.

or

Run npm run build and tell me when it is finished.

or

Use Get-ChildItem to list files in C:\Windows\System32 and notify me when the operation is complete.

Notes

The issue appears more frequently with:

• Large Rust workspaces
• Large Node.js projects
• Repository indexing operations
• Commands producing significant terminal output
• Long-running filesystem scans

The problem does not appear to be tied to a specific project and can be reproduced across multiple agentic frameworks and coding assistants. But note the builds should be large to actually check the agents capabilities.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.172

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

These might feel a minimal solution but i really think we need a permanent solution for these Issue for agents running in a wrong loops!