Chat Input Field Disappears During Sub-Agent Execution

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The chat prompt window vanishes while a sub-agent is running. This prevents me from continuing the conversation or providing further input until the process is complete.

Steps to Reproduce

I just gave an assignment to a sub-agent write technical documentation. I saw this happen on my colleague’s cursor then reproduced it on my machine as well.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.3.12
VSCode Version: 1.105.1
Commit: 75c0dfd29aecf2cc208dbaf761d5cc459c601aa0
Date: 2026-05-06T03:47:52.249Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.5.0

For AI issues: which model did you use?

Does not matter, my colleague used composer 2, i used gemini 3.1

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

I just noticed the screenshot says it’s running Composer-1 when I asked it to use gemini 3.1 and the agent has “inherit” model turned on

Hey Nikolay, thanks for the forum post! Currently, this behavior is by design - when you click into a subagent’s conversation, the input is intentionally hidden. Subagent transcripts in the IDE are read-only “drill-in” views today; new prompts go through the parent agent that spawned it.

To get the input back, click back into the parent agent’s conversation. The subagent keeps running in the background, and you can continue chatting from there.

However, we have an open item in progress to make this more clear and indicate to users more clearly how to get back to the main agent to continue the conversation.

On the “Composer-1” label you noticed: that’s a separate, display-only issue we’re already tracking. The model that actually ran should match what you selected (Gemini 3.1); only the header label can lag. We have that in the backlog to sort out. Thanks again for the detailed report!

Hi Kevin, I did not click into the subagent’s conversation. This is my main chat window. If by any chance Cursor navigated me to the sub-agent’s chat window then this is a bug. I did not intentionally go there. How can I go back to the main chat then? I just witnessed this happen again this morning.

@kevinn Right after my last message, I authorized a GitHub command via a subagent. As soon as I clicked ‘Allow,’ my main chat window disappeared. I’m now stuck in the subagent’s thread with no visible way to navigate back to the main conversation.

Thanks for the detail, Nikolay, and sorry for the delay in following up.

When a subagent needs approval (like that GitHub command), clicking “Allow” can shift you into the subagent’s thread. Those threads are read-only right now, so they intentionally have no input box — but we’re not making it clear you’ve been moved, or how to get back. We have an open item to fix that.

You haven’t lost anything, though — your main chat is still open, and the subagent keeps running in the background. To get back: click your main chat’s tab (or reopen it from the chat history / agents list). The input box returns, and you can keep chatting.

I assume you’ve probably Cursor since this post and may have noticed that newer builds have some improvements here. Let us know your thoughts and if you still have feedback on how we handle subagent interactions.

@kevinn Yep I have figured as much since I posted. I haven’t since this behavior since, I always update to the latest released version so perhaps this was addressed already. I would love to see an option to chat directly with the sub-agent.