Sharing monitored terminals with Cursor context

So this is clearly sort of a half built feature but I’d like it to be more intentional. I’ve worked out that if I ask Feature run command in a terminal it can monitor it’ll launch the terminal in the editor. This is great for jest, vitest, and especially running a dev console. I’m sure other frameworks will find it similarly useful.

The problem is that (a) it only works in composer and (b) I can’t drag a running terminal into context. So by the time I realize I need Cursor to analyze a terminal output it’s too late, I have to recreate the whole thing in a monitored terminal, which means the time to shut down other terminals, run a new one via prompt, compile, potentially reload and futher compile, run the command set again, and THEN show it to Cursor.

Still worth it.

Just a giant PITA.

1 Like

Side issue

CMD-K is your focus mode in Cursor but it’s a terminal primitive for clear. That can be almost as annoying a default as 1Password’s browser hotkey.

Can you do a more in depth explaination – I only have like a 5% understanding of what youre explaining, and 0% understanding on how to launch “monitored terminal” and 0% on how to parse

…“t if I ask Feature run command in a terminal it can monitor it’ll launch the terminal in the editor. …”


I think I want what you want, but I need a better understanding of how to fidddle me stix.

I may have tapped into an unreleased feature? It stopped working about 4h after making this post. Used to be I could type “Run pnpm dev in a terminal that you can monitor” and it would pop the terminal into an editor window, adding it to context like a file. Best feature since the addition of agents. It let me run both unit testing and server logs right into the Composer review without any copy & paste.

Thing of beauty.

Okay now it’s back. It’s just very inconsistent.

I ask my yolomode instructions to do this and it’s reliable enough in doing what you said.

Yeah I’ve worked out it’s internally called a background terminal. Odd feature in that it’s incredibly powerful while also being totally undocumented and kind of partially integrated. You can create one if you know how to do it but you can’t drag or add it into context after the fact.

It also doesn’t know how to stop and start it’s own processes, so it tends to open a new terminal every time it wants to restart a low level service, whcih means it increments ports like crazy during certian types of work.

I double down on this feedback, even though you can attach terminal output as context.

The reality is that if you run commands from chat, the AI monitors it in real time and automatically knows what the issue is and recommends a fix.

And, to be honest, AI is WAY WAY better than almost all of us at following terminal output, even understanding it at all.

My feature suggestion that the primary terminal or the first terminal in the list of user terminals (the ones that go under the file panes), just the first one, is automatically monitored by the Composer or Chat.

Often the error output is super long, and trying to highlight it all is a big pain just to send it to the Chat.

I often run commands from the chat, but I have to “chat” with the chat, which takes time because so many people are using Cursor and Anthropic you have to wait a long time just to have the Chat AI load up a terminal command.

2 Likes

Yeah the inability to continue to work with a common terminal makes me crazy, especially with the dreaded “let’s reset the dev server” tool request, which means stopping my current terminal with the comparative previous output in order to avoid port drift, or resetting the current terminal and pointing out the result (burns a request token instead of using an agent continuation)

1 Like