CodeMote

Getting notified when Claude Code is waiting

By Salvatore Castellitti, developer of CodeMote · 25 July 2026

There's a failure mode with coding agents that took me embarrassingly long to notice in my own behavior. I'd give Claude Code a task that should take twenty minutes, and then I'd sit and watch the output scroll instead of doing something else. Why? Because the one time I did walk away, the agent had stopped ninety seconds in to ask permission to run npm install, and it sat there waiting for half an hour while I was in a meeting.

The permission prompts themselves are good. I want to be asked before an agent runs a migration or touches something outside the repo. The problem is that a silent pause turns "the agent works while I do other things" into "the agent might be working, better keep watching." At that point you've lost most of what the agent was supposed to buy you.

What fixed it for me was boring: OS-level notifications when the agent needs input.

The setup

My agents run on a VPS behind the CodeMote host; the full server setup is in an earlier post. Short version:

# on the host machine, once
npm install -g @anthropic-ai/claude-code && claude login

# in the project
npx codemote-cli start

Pair a browser at the connect page, open an agent chat, and accept the browser's notification permission prompt when the workspace asks. That last step is the whole feature.

What you get pinged for

The notification I care about is "the agent is waiting for you." When Claude Code hits a permission gate, the run pauses, and the workspace sends an OS notification even if the tab is buried behind other windows or you're in a different app.

Clicking through lands on the prompt itself: the exact command the agent wants to run, with approve and deny. Answer and the run continues.

Completions ping too, which closes the loop from the other side: I review the diff when there's a diff, instead of checking the tab every few minutes out of nervousness. When you're already looking at the workspace, the same events show as in-app toasts instead of OS notifications, so it doesn't ring twice for something on your screen.

The difference in practice

Before notifications, an agent run held my attention the way a pot on the stove does. Not demanding, exactly, but I couldn't fully leave. In practice I got maybe one supervised run into a workday, because each one occupied a slot of attention.

Now the shape of the day is different. Morning: write a decent brief, start a run or two, close the tab (the sessions live on the server, so closing the tab costs nothing). During the day: a notification arrives, I answer a permission prompt in under a minute, back to whatever I was doing. Evening: review diffs, run the tests myself in the workspace terminal, commit or push back.

Two or three real agent tasks now happen in the margins of a normal day. The agent didn't get better; the waiting got visible.

One warning from experience

The tempting shortcut is to pre-approve broad permissions so the agent never pauses at all, and I tried that for a while. It stops the interruptions, and it also stops you from seeing what the agent is actually doing at the moments that most deserve a look. I went back to keeping the gates on. Notifications make each gate cost seconds, and at that price there's no good reason to remove the leash.

If the babysitting posture sounds familiar, the fix costs one browser permission. Beta signup is on the homepage.