tl;dr: let coding agents access runtime output
I’m pretty sure this isn’t novel, and I’m almost certain many people already do some flavour of this, but it’s been the single biggest unlock in my local AI-assisted development with Cursor, and it’s so simple I want to share it.
If your coding agent can’t see what your program is doing, it can’t debug it
Cursor doesn’t have some magical ability to read everything happening on your machine. Unless you explicitly expose your output, the agent is effectively blind.
When I let it see my program’s output, I found that it could solve problems that used to take me 30 minutes in about 30 seconds and free up my time to spend on other areas of the startup.
This post is me sharing how I let Cursor see my program’s outputs.
The problem:
Currently, my local dev setup has three moving parts:
- a Python FastAPI backend
- a React frontend
- a Python FastAPI auth router which speaks to WorkOS to allow authentication
All three emit logs.
All three can fail independently.
All three can require debugging to get back up and running.
Cursor can run commands you ask for, or even come up with some that it thinks might be useful, but it cannot:
- attach to a terminal window you opened yourself
- read real-time stdout/stderr
- watch a hot-reloading server
- magically see your browser’s console logs
And when the agent tries to “fix” something by killing your running server or client, it destroys your whole hot-reloading setup. Now you have to put everything back up again just to continue. This can kill your productivity in a big way.
The unlock:
Coding agents can be more capable than you’d expect, and sometimes the best thing you can do is simply ask whether something you’re wondering about is possible. At one point, I asked: “Can you read something inside a screen session?”
To my surprise, Cursor told me:
If you run ’screen -X hardcopy’, I can read the output.
Then I asked Cursor if it could check the current screens that were running using screen -ls and find the last 50 lines of the server’s output. It did.
This gives the agent something to look at beyond just the code.
How I set it up:
I use runnem, a tiny tool I built for a different reason entirely: to remember your run setup and let you switch between multiple projects seamlessly.
It runs each service inside its own screen session, and that just so happens to make this unlock possible. But you can use anything:
- standalone screen
- tmux
- Docker
- setting up logging to a file on disk
The principle is universal.
With runnem, Cursor can:
- list sessions with screen -ls
- identify backend and frontend sessions
- dump the relevant session’s output to disk without interrupting them
- analyse logs while keeping everything up and ready to hot-reload on the next code change
My .cursor/rules snippet:
To guide the agent, I’ve added this to my .cursor/rules file.
If you need to check backend or frontend logs just ls all the active screens and then use a command like this:
“screen -S 94383.runnem-flow-myna-server -X hardcopy /tmp/backend_logs_200.txt && tail -200 /tmp/backend_logs_200.txt”
The screen with the ‘-server’ suffix is the backend and with the ‘-app’ suffix is the frontend.
Sometimes I still explicitly tell the agent to “check the logs using screen -ls”, and that’s enough for the agent to get into a loop that fixes errors until the server is running again.
Do you need runnem?:
No. Use any setup you like.
But runnem coincidentally makes this workflow very easy because:
- each service has its own named screen
- I run three services across two languages
- the agent needs to cross-check all of them
- everything stays running with hot-reload intact
I’ve been wanting an excuse to experiment with MCP, so I might try adding an MCP tool for runnem that lets Cursor talk to it more directly (for example, exposing “get backend logs” as a single tool call). But for now, this simple screen-based setup has been more than enough.
The final takeaway:
Once your agent can see your program’s output, it goes from:
editing files based on guesses
to something much more powerful:
responding to reality
If you’re running multiple services locally and want the agent to pull its weight:
Expose the output. Give it vision.
It’s a tiny setup change, but it has completely transformed how I work with AI.
Are other coding agents doing this already?
At the moment I don’t have the bandwidth to experiment with other coding agents. So there may well be setups like this included in those agents, or ways to nudge you into a similar workflow because it’s so powerful.
On the other hand, maybe they don’t build this in because the languages and frameworks they have to interact with are so varied.
I’d love to know in the comments what setup you use if you do things in a similar way! Especially if you’ve found a good way to give your agent visibility into the browser console logs that’s reliable and simple to setup.
A more detailed post can be found here: https://dsmurrell.com/articles/cursor-runtime-output
Top comments (0)