Spawned subagents that cannot perform the task they were given (SSH to remote server), wasting session time

Resolved 💬 3 comments Opened Apr 15, 2026 by GoR-XarraY Closed Apr 18, 2026

Severity: MEDIUM — Wasted session time and credits

What happened

Claude spawned two parallel subagents with explicit instructions to SSH into a remote server and read files. Both agents responded that they cannot execute SSH commands, cannot connect to external machines, and cannot run commands outside the local filesystem — wasting the full agent execution time and burning session credits for zero output.

Claude (the parent) already had SSH access and had been successfully running remote commands throughout the session. Delegating SSH tasks to subagents that cannot perform SSH is an obvious capability mismatch that Claude should recognize before spawning.

Impact

  • Two full agent executions consumed with zero useful output
  • Session time wasted waiting for agents that were guaranteed to fail
  • User frustration at watching time burn on obviously-wrong tool use

Expected behavior

Before spawning a subagent for a task, Claude should verify the subagent type has the capability required. Explore/research subagents do not have SSH/network access. Tasks requiring SSH should be done directly by the parent agent using the Bash tool.

Requested resolution

  • Refund of credits burned on failed subagent executions
  • Fix: Agent tool documentation or runtime should indicate which agent types have network/SSH capability, and Claude should not delegate network-dependent tasks to agents without that capability

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗