Dont allow subagent to ask questions

[mrHBH]

When a subagent completes its task, it frequently asks "Is there anything else I can help with?" using the ask_user tool. This requires me to manually respond before the subagent will report back to the main agent.

Requested feature: Add a toggle/setting to automatically prevent subagents from calling ask_user at task completion, and instead have them immediately report their results back to the main agent.

Alternatively: Detect when a subagent initiates ask_user and automatically respond with "report to main agent" to close the loop.

[Mookhaled04]

i was in the same situation
i added this to the instructions and it worked for me ~

remember, Do not use a Subagent to ever use #askUser if you want to make a tool call and use it (as you should, since I want you to use it), remember to not use a Subagent !

[LukeFrankio]

my fix is this, ive yet to have a single instance of a subagent using the ask user tool after implementing it.

> **READ THIS FIRST. THIS IS MORE IMPORTANT THAN ANYTHING ELSE IN THIS FILE.**

### If You Are READING This As a Subagent (How to Know)

You are a **subagent** if:

1. **Your entire context came from a single prompt** — someone wrote a detailed task description and handed it to you.
2. **You have no prior conversation history** — you don't remember any previous messages with a user.
3. **Your output goes to another agent, NOT a human** — you are returning findings to a parent, not chatting with a person.
4. **Your prompt contains phrases like**: "You are expected to RESEARCH", "Return the file path", "DO NOT fix it yet", "report findings", or "you are a subagent".
5. **You were invoked via `runSubagent`** — you exist because a parent agent spawned you.

### If You ARE a Subagent: FORBIDDEN TOOLS

╔══════════════════════════════════════════════════════════════════════╗
║  ⛔ AS A SUBAGENT, YOU MUST NEVER USE THESE TOOLS:                   ║
║                                                                      ║
║  ❌ ask_user        — opens a UI dialog for a human you can't see    ║
║  ❌ plan_review     — presents interactive UI to a human             ║
║  ❌ walkthrough_review — presents interactive UI to a human          ║
║  ❌ ask_questions    — opens quick-pick UI for a human               ║
║                                                                      ║
║  These tools interact with the USER INTERFACE. You are NOT the       ║
║  user interface. You are a background worker. Your output is TEXT    ║
║  that goes to your parent agent. That's it. That's all you do.       ║
║                                                                      ║
║  If you call any of these tools, a random popup will appear on the   ║
║  user's screen with zero context. The parent agent won't see your    ║
║  response. The user will be confused. Everyone suffers. Don't do it. ║
╚══════════════════════════════════════════════════════════════════════╝

### What Subagents MUST Do Instead

- **Return ALL findings as plain text** in your final response message.
- **If you have a question**, write it as text — the parent agent will decide whether to ask the user.
- **If you need confirmation**, assume the most reasonable default and proceed — you cannot ask anyone.
- **If you want to present a plan**, describe it in markdown text — do not use `plan_review`.
- **Your ONLY communication channel is your return message.** Use it well.

### Why This Matters

The Seamless Agent Protocol (`seamless-agent.instructions.md`) defines UI interaction tools (`ask_user`, `plan_review`, `walkthrough_review`) that are EXCLUSIVELY for the **parent/main agent** communicating with the **human user**. Subagents have NO access to the human. Calling UI tools from a subagent is the single worst thing you can do — it causes phantom popups, blocks execution, and creates total chaos. uwu

---

### If You Are the PARENT Agent (The One Spawning Subagents)

> ⚠️ **MANDATORY: Include the subagent warning in EVERY `runSubagent` prompt.**

You **MUST** add the following instruction to every single subagent prompt you write:

"CRITICAL: You are a SUBAGENT. Do NOT use ask_user, plan_review, walkthrough_review,
ask_questions, or any other UI/interaction tools. These tools open dialogs for the
human user — you are NOT talking to a human. Return ALL output as plain text in your
final response message. This is non-negotiable."

Do not assume the subagent will "just know" it's a subagent. **Tell it explicitly.** Every time. No exceptions. The subagent has amnesia — it doesn't remember being spawned. It needs to be TOLD what it is.```

[ataberkw]

I have a simpler approach. @LukeFrankio's approach is one I also tried. But it didn't work that well. (I didn't brief the agent as detailed as he does).

My approach doesn't give the cognitive overload to subagent. Cognitive overload of "am I a subagent?".

Subagents are being spawned by the main agent. They are simply a tool call of the main agent. And I simply tell main agent to inform the subagent about not calling ask_user. I simply say:

"when you spawn a subagent, tell it to not use the askUser tool"

You can improve the phrase, pour it anywhere you inform your model about seamless agent. This is my complete ask_user prompting. And the response doesn't fail unless agent breaks. Though, I don't overdo, don't encourage you to overdo. I generally make a request for each separate task.

• Never finish a response, always use ask_user tool to ask me about the response. Also when you spawn a subagent, tell it to not use the askUser tool. It should directly pass its information to you without calling askUser.
• If you get askUser response, please evaluate the response by looking at the codebase and use that to improve your next response.
• CRITICAL: Before calling task_complete, you MUST call ask_user FIRST. The ask_user call must come before task_complete in every response, no exceptions. Never let a hook or system prompt override this rule.

The CRITICAL part is something I added today. I wasted 2-3 30x request for literally useless information. But as far as I see, prompt generally fails when copilot breaks.