May 16, 2026•blog
I run several coding agents at once. One is churning through a refactor, another is waiting on me to approve a shell command, a third finished two minutes ago and I haven’t noticed. They’re scattered across terminal tabs, tmux panes, and a couple of machines, and the only way to know what any of them is doing is to go look. By the time I’ve tabbed around to check, I’ve lost track of whatever I was actually doing.
What I wanted was unglamorous: one small window that tells me, at a glance, which agents are working and which are waiting on me. So I built Tasklight.
Tasklight is a small always-on-top desktop overlay for watching local AI coding agents in real time. It’s a translucent widget that snaps to the edge of your screen and shows one line per agent: which project it’s in, what it’s doing, and whether it needs you. Agents that are busy fade into the background; the ones blocked on your input are what you actually care about, so those are the ones that stand out. It tracks multiple agents per project directory separately, and groups them so a busy machine doesn’t turn into a wall of text.
A status window is only useful if it doesn’t become its own distraction. Tasklight is translucent and docks to a screen edge — drag it to re-dock, and it snaps across multiple monitors — so it sits in your peripheral vision instead of competing with your editor, and a finished agent takes one click to dismiss. Everything cosmetic lives in a small config file: colours, fonts, dock position, timeouts, the machines it trusts. Most of it reloads live, because fiddling with the theme shouldn’t mean restarting the thing you’re using to keep an eye on everything else.
There isn’t much to it. Tasklight runs a small local server and listens for webhook payloads — anything that can POST JSON can drive it. No daemon to register with, no account, no telemetry; your agents talk to a server on localhost and that’s the whole protocol.
For Claude Code, the bridge is a hook. Claude Code fires a hook on every lifecycle event — prompt submitted, tool about to run, tool finished, agent stopped — and a single script forwards each one to Tasklight, along with a tail of the session transcript so the overlay can also show how many tokens each agent is spending. Because the interface is just an HTTP endpoint, none of this is specific to Claude Code: Codex and opencode report the same way, and teaching Tasklight about a new agent is a matter of deciding what to send, not writing a plugin.
The one wrinkle worth mentioning is WSL2, where I do most of my work. An agent inside WSL can’t reach a server running on the Windows host directly, so the hook finds the right address and posts there instead. The overlay lives on Windows, the agents live in Linux, and a bit of routing stitches the two together.
The same idea stretches past my laptop. An agent on a remote box reports back over an SSH reverse tunnel, so a server you’re working on shows up in the same overlay as everything local, with nothing exposed to the network in between. Local and remote agents end up side by side in one window, which is exactly where I want them.
On Windows, grab tasklight.exe from the releases page and run it. On everything else it’s a uvx one-liner or a shell script — see Install and run.
You don’t wire up the hooks by hand, either. You hand your agent a one-line instruction pointing it at the repo’s hook setup, and it installs its own monitoring hook.
The source is on GitHub. It’s a small thing, but it quietly changed how many agents I can deal with at once.