Agent Execution Timeout: Persistent Hanging During Complex Tasks

I'm also seeing the claude process chewing 100% CPU during these long hangs.

Hard to know if it's genuinely just the agent doing a lot of work (without that work being visible in the UI) or whether something's genuinely hanging. Given the 100% CPU I'm inclined to think something is hanging.

I'm also seeing keyboard input frozen if I try to Esc out of the hung subagent. I've had to terminate the claude process a bunch of times now today.

I'm also seeing keyboard input frozen if I try to Esc out of the hung subagent. I've had to terminate the claude process a bunch of times now today.

Exact same thing for me.

Same problem. I even tried to update the agent prompts to force the agent to return the control when finished and told them not to call itself at any cost, but no success. All of my agent usage attempts ended up in the way that the agent called itself and never returned the control. Token usage stopped as well, it just hangs.
When I expand it (via ctrl+r), it seems the agent partly did it's job, then it is stopped half way.

While I wrote this comment. one of the running agent managed to finish. Another agent asked me to approve some command executions, after 200-300 seconds of hanging (it is not updated the used token number though). It is even froze the terminal after some runtime. It seems very random behavior.

I'm seeing the same thing repeatedly for the past couple of hours. Perhaps it's happened once before the .63 (Windows) upgrade for me. Timer doesn't increase, tokens doesn't increase and it never moves or progresses the currently running tasks. The tasks that have hung have been a mixture of big and small. If I attempt to resume a session, the latest interactions are not available. All I can do is kill and restart a new session.

To add some context, I've encountered the following subagent behavior:

Problem Summary
When Claude uses the Task tool to invoke subagents (Task(subagent_type="subagent-name")), it creates recursive subagent spawning that leads to infinite loops and session timeouts (~500 seconds).

Expected Behavior
Task tool subagent invocation should work cleanly like direct user invocation with @agent-[name] syntax.

Actual Behavior
Task tool invocation creates nested subagent loops:

subagent-name(task description)
  ⎿  Listed 10 paths (ctrl+r to expand)
     subagent-name(nested task)
     +1 more tool use

Reproduction Steps

1. Create a subagent in .claude/agents/ with proper YAML frontmatter
2. Have Claude invoke the subagent using Task(subagent_type="subagent-name", prompt="test")
3. Observe recursive spawning and eventual timeout

Working Workaround
Direct user invocation works correctly:

@agent-subagent-name [prompt]

Results in clean execution without nesting.

Environment

• Claude Code version: 1.0.63
• Platform: Linux (Pop_OS! 24.04)
• Subagent files: Properly structured with YAML frontmatter

Impact

• Blocks programmatic subagent usage in frameworks
• Causes sessions to get stuck and max CPU usage
• Prevents automated workflows that depend on subagent validation

Additional Context
This issue prevents building educational frameworks that rely on subagent validation workflows. The recursive spawning suggests the Task tool may be triggering Claude Code's internal subagent mechanism inappropriately.

Thanks @JaimeStill but

@agent-subagent-name [prompt]

This workaround doesn't work for me

@FredHasselot

Thanks @JaimeStill but @agent-subagent-name [prompt] This workaround doesn't work for me

It was working for me this morning. Some additional details for verification:

• I have to be the one to directly invoke the subagent. Having the main agent invoke the subagent with this syntax still introduces the hung session behavior.

• Verify that the agent you're trying to access is available with the /agents command. Whenever you start typing the agent name and press tab, you should see autocompletion for agent-[agent-name].

@sobri909 I confirm the CPU usage peak, also in RAM. My MacBook normally works without increasing it temperature and I noticed it is heating too much, then I find out why: 4 claude processes running non stop consuming over 8GB RAM in total.

<img width="837" height="179" alt="Image" src="https://github.com/user-attachments/assets/adbce4cf-e5c8-4fd3-929c-267e2a264fed" />

@JaimeStill Thanks for the suggestion! Unfortunately, I've tried the direct invocation method with @agent-subagent-name [prompt] but it doesn't work for me either.

I'm experiencing the same symptoms as others:

• CPU usage at 100% on my Mac (recent model)
• Sessions hanging indefinitely
• Having to kill the process to recover

Currently on v1.0.63 and the issue persists.

CPU usage by claude code hung session, even after permanently close Windsurf console, as well as RAM as I previously shared. Is it anthropic using our PCs for training models? lmao

<img width="908" height="181" alt="Image" src="https://github.com/user-attachments/assets/672d99e6-1be9-4c8b-a284-7b4c71d13154" />

I have the same problem with Claude Code freezing and stay stuck, until I hit "ESC" which will totally block Claude Code (didn't checked CPU usage btw) : https://github.com/anthropics/claude-code/issues/4580#issuecomment-3137696570

Problem solved for me with .64 update

Same here!

After rebooting Claude Code, the timeout issues seem to have been resolved with v.64.

I see in .64 change log "Agents: Fixed unintended access to the recursive agent tool" and for now it seems fixed the issue, but not tried yet to run multiple claude instances in parallel which starts sub-agents.
Additionally - while running a sub-agent, token usage is not updated (even ccusage cannot see it as long the agent is not finished it's job), it will be shown only when the agent finished it's work, but even then the "main" counter is not update, it just shows in the agent result how many tokens was used. Not a critical thing, just a little harder to track the usage accurately.

@gabix89 correct. Same behavior. Main problem that was nested agent invokes is solved, other minimal details still failing

This issue has been fixed as of 1.0.64. Please feel free to re-open if you're still seeing it.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.