I've been using Codex and Claude Code a lot lately, and I kept running into the same slightly ridiculous problem.
I'd give an agent a task, let it work, walk away from my desk — and then come back a few minutes later just to see what happened. Most of the time I wasn't even coming back to send another prompt. I just wanted to check the diff, open a file, see whether the app still worked, or find out if the agent was waiting for me.
After doing this enough times, I realized the chat wasn't really what I was missing. I wanted the rest of the project to stay within reach while the agent worked.
The chat isn't the whole task
A coding-agent session is only one part of what's going on.
There's the conversation, but there's also the repository on disk, the current Git state, the files themselves, and usually a dev server somewhere in the background.
The transcript is useful because it tells me what the agent tried to do. But when I want to decide whether the result is actually good, I end up looking at the project.
Did the right files change? Does the code make sense? Does the app still start? Does the UI look right?
I also don't think a tool should pretend it knows more than it does. If the working tree contains a change, that doesn't automatically mean a particular agent created it. I might have edited the file myself, another process might have touched it, or the change might already have been there.
So I became less interested in reconstructing some perfect "agent state" and more interested in putting the real project state next to the agent session.
The mental model I ended up with was:
Observe → Review → Steer
See what the agent is doing, inspect the actual result, then decide what should happen next.
For my own workflow that usually becomes:
Chat → Changes → Files → Preview → next prompt
The missing piece was being able to do that without staying in front of the terminal.
So I built DeskCue
That experiment turned into DeskCue.
It's an open-source, local-first tool that runs alongside the coding tools already on my machine. Instead of replacing Codex or Claude Code, it gives me one place to look at the task around them.
Right now that includes things like:
- existing Codex and Claude Code sessions
- project changes
- file browsing
- a running app preview
- follow-up prompts and stop controls
- notifications when something needs attention
It also works with Ollama, LM Studio, and generic CLI sessions.
Supporting several tools wasn't really the original goal. I mostly wanted the surrounding workflow to stay useful even if I switched agents or used a local model for something.
The important part is that the agent is still running on my computer, against the real project. DeskCue just gives me another surface for reviewing and steering that work from a laptop, another computer, or my phone.
A quick look at the current flow: session → changes → files → preview.
Why I kept it local
This part was actually one of the easier decisions.
The repository is already on my machine. The dev server is already running there. The coding agent already has the environment it needs.
Uploading the project somewhere else just so I could inspect it remotely felt like adding another copy of the same state for no good reason.
I'd rather keep one real development environment and expose the parts I care about.
That means the file I'm opening is the actual file in my workspace. The Git diff is the actual working tree. The preview is the application that's already running as part of my development setup.
Of course, local-first creates its own problems. Remote access needs authentication. Device credentials need to be revocable. Notifications have to reach me without turning the whole thing into a hosted IDE. Different agent tools expose their sessions differently.
There's quite a bit of boring plumbing behind what looks like a simple UI.
But I prefer that to having a second development environment slowly drift away from the first one.
The phone use case was different from what I expected
At first I thought about DeskCue mostly as a way to use coding agents from a phone.
I don't really describe it that way anymore.
I don't want to replace my workstation with a phone, and I definitely don't want to spend the day writing long coding prompts on a tiny keyboard.
The useful case is much simpler.
I start a task at my computer and leave the agent working. Later I want to know whether it finished and whether the result is worth keeping.
Sometimes that means looking at the diff. Sometimes I only need to open one file. For frontend work, I often just want to see the app.
If the agent is stuck on a decision, I can answer it. If everything looks good, I can send the next prompt and move on again.
That's enough.
The phone isn't where I do the development. It's just a convenient place to keep an eye on the task when I'm away from the machine.
Notifications make this much more useful too. I'd rather get one notification when something actually needs my attention than keep opening a terminal to see whether the agent has finished.
What I've learned from building it
One thing I've become more aware of is how easy it is for a tool around coding agents to turn into another IDE.
You add a session view, then you think it needs a terminal. Then an editor. Then Git controls. Then model selection, orchestration, deployments...
Eventually you're building a platform instead of solving the original annoyance.
I'm trying to keep DeskCue on the other side of that line. I don't want it to become the agent, the editor, or the model host. I want it to stay focused on reviewing and steering work that's already happening.
A few other things became clearer along the way.
I still trust the workspace more than the transcript
The transcript is useful context, but the code I'm eventually going to commit lives in the repository.
When the two disagree, I care about what's actually on disk.
A diff tells me what changed, not why
That's completely fine.
I don't need the UI to invent attribution. Showing the real working tree is already useful enough.
Preview is one of the screens I use most
This surprised me a bit.
For frontend work especially, I often don't care about another detailed explanation of what changed. I want to open the app and see it.
Does the page still work? Is the spacing weird? Did the agent misunderstand the layout?
A few seconds in the actual app often answers that faster than reading the transcript.
Supporting multiple agents isn't enough by itself
DeskCue can work around Codex, Claude Code, local models, and generic CLI sessions, but I don't think "one UI for multiple agents" is a particularly strong reason to use something.
The part I find useful is having the same review loop around them.
I may switch the tool doing the work, but I still want to inspect the project, look at the app, and decide what happens next.
Where DeskCue is now
It's still an alpha.
I've mainly tested it on Windows and Ubuntu so far. macOS still needs more verification, and installation is currently from source rather than through a packaged installer.
It's open source under Apache-2.0:
github.com/AleksandrKornev/DeskCue
There's still plenty I want to improve, especially around the point where an agent needs human input and you want to get back into exactly the right context.
But the basic loop has stayed pretty much the same since I started:
agent works → review the project → decide what happens next
I'm curious how other people deal with this.
When you leave a coding agent working on a task, what do you actually want to see before deciding what to do next?
Top comments (0)