Erratic Task/Subagent Behavior in Plan/Act Workflow: Premature Edits, Nested Plans, and UI Flickering

[BobbyWang0120]

Bug Description
Description:
I'm writing to report a critical issue regarding the inconsistent and buggy behavior of the Task/Subagent feature within the plan/act workflow. While the Subagent capability is incredibly powerful, its current instability presents several significant bugs that disrupt the user experience, especially within the widely-used plan/act model.

Detailed Problem Descriptions:

Subagents Prematurely Modify Code in Plan Mode: When the main process is in plan mode, the intended purpose of a Subagent is to perform read-only analysis and information gathering to help formulate the plan. However, I've observed that these Subagents sometimes begin to actively modify code directly. This completely violates the core principle of the "plan first, act later" workflow, as the codebase is altered without user approval before a plan is even finalized.

Subagents Create Confusing "Nested Plans" Requiring Approval: In other cases, a Subagent correctly attempts to gather information, but it appears to operate in its own nested plan mode. It will generate a sub-plan on "how to collect the information" and then interrupt the primary workflow to ask the user to approve this sub-plan. This is confusing and disruptive, as the user should only need to approve the final, high-level plan, not the intermediate steps of how that plan is formulated.

Suspected Root Cause & Suggestions:

I believe the root cause of these issues is that the initial prompt, context, and permissions passed to a Subagent from the main thread are not being properly defined and isolated when in plan mode. The Subagent acts erratically because it doesn't seem to "know" that it should be operating in a restricted, read-only planning phase.

To address this, I would like to propose the following solutions:

Suggestion A: Implement Strict Sandboxing for Subagents in Plan Mode. When a Subagent is activated during plan mode, it should be strictly sandboxed with limited permissions. This means granting it read-only access to the filesystem and permissions for web-related operations (like searches) only. All "write" or "modify" capabilities should be completely revoked.

Suggestion B: Disable Nested Planning Behavior for Subagents in Plan Mode. During the planning phase, Subagents should simply execute their information-gathering tasks and return the results to the main thread. They should not create their own sub-plans that require separate user approval.

The Task/Subagent feature is one of the most promising aspects of Claude Code, but its current instability in the critical plan/act workflow is a pressing issue that needs to be addressed.

Additional Bug Report (P.S.):

There is also a related UI bug. On macOS, in both the native Terminal and iTerm2, there is a high probability that after a plan is approved and a Task begins, the entire terminal screen will start to flicker erratically until the task is completed or interrupted. This appears to be a UI rendering or state update bug.

Thank you for your hard work on this project!

Environment Info

• Platform: macos
• Terminal: iTerm.app
• Version: 1.0.22
• Feedback ID: 210febd6-621f-46d6-8819-3d7ccb09b94b

[adamavenir]

I've had incredibly unhinged behavior from subagents. They seem prone to doing a lot of stuff that they were not asked to do, even completely irrelevant.

I've had them stay in a loop for enormous amounts of time achieving nothing of value; they can plow through a session and compact and then continue and compact and continue again... I just watched out of morbid curiosity as they ran and re-ran the tests, created 15 test-xyz files...

[BobbyWang0120]

I've had incredibly unhinged behavior from subagents. They seem prone to doing a lot of stuff that they were not asked to do, even completely irrelevant.

I've had them stay in a loop for enormous amounts of time achieving nothing of value; they can plow through a session and compact and then continue and compact and continue again... I just watched out of morbid curiosity as they ran and re-ran the tests, created 15 test-xyz files...

Yes, I completely agree. When subagents work well, they can significantly speed up a task. But too often, they end up being counterproductive.

I think the core issue is that subagents need to be structured to serve the main task exclusively. They should have a lower priority or a more constrained role, rather than acting like a completely new Claude instance that can go off on its own. I hope the Claude Code team can figure out how to make subagents better serve the primary goal.

[adamavenir]

And if you interrupt to correct them, it breaks out of the agent permanently and back to the parent Claude that sent them on the task, who says, "What are you talking about? I wasn't doing that. I haven't even done anything yet!" 😂

[adamavenir]

Classic example -- it completely built a one-shot LSP based on this question.

[lujstn]

I have specifically found the planning agent has repeatedly started to change code by itself, this just happened again:

This has coincided with a massive regression of Plan Mode's functionality in general, which I've added to in #2008

[apetta]

An interesting case is when the subagent/Task presents the plan instead of the parent agent - If you reject it to provide further guidance, the plan is swallowed by the Task agent that got interrupted (& cleared from the terminal). The feedback/prompt submitted after this goes to the parent agent & it doesn't seem aware of the 'plan' submitted just before.