moriblink
Early access
The problem with parallel agents
Running two or three coding agents at once is now normal: one refactors, one runs tests, one writes a feature in another worktree. The hard part is not starting them. It is noticing which one has stopped and is waiting for you. An agent that waits ten minutes for an approval wastes those ten minutes.
To keep parallel sessions moving, you need to know four things about each one:
- Is it waiting for me? A permission request or a question stops the agent until you answer.
- Did it finish? Finished work is ready for review.
- Did something fail? A failed build or test changes what you do next.
- Why is it slow? A long run can be a slow build, a retry loop, or time spent waiting for you.
Free setup: one alert per agent
Every major coding agent can run a command when it needs you. Set up alerts for each agent that you use:
- Claude Code:
PermissionRequest,Notification, andStophooks. - Codex CLI: built-in
[tui]notifications,notify, and aPermissionRequesthook. - OpenCode: built-in
attentionalerts or a small plugin.
Put the project name in each notification. Without it, three identical “needs permission” alerts do not tell you which window to open. The Codex guide includes a script that adds the project folder name.
Keep parallel sessions apart
- One worktree per session.
git worktree add ../feature-x -b feature-xgives each agent its own folder, so their edits do not collide. - One terminal tab or window per session. Name each tab after its task.
- Approve less often. Each agent has permission settings that can allow safe, routine commands. Fewer prompts mean fewer stalls. Keep approval for commands that change things you care about.
Finding out why a run is slow
When a turn takes ten minutes, the total time hides the cause. Split it into the steps that used the time:
- Waiting for you. Approval and question time is not agent work. If it is large, the fix is faster alerts, not a faster model.
- Long tool calls. A full build or test suite can take most of a turn. A focused test command can save minutes on every run.
- Repeated steps. The same failing command run again and again is a sign of a retry loop.
- Unmeasured gaps. Some time is model thinking or time the agent did not record. Treat it as unknown, not as a specific cause.
A timeline of the turn shows these at a glance. Without one, you have to read the transcript and add up times yourself.
DIY alerts compared with MoriBlink
| Notification hooks | MoriBlink | |
|---|---|---|
| Alert when an agent needs approval | Yes, one per agent setup | Yes. Mori appears on your current display. |
| One list of all sessions | No | Yes, across connected projects |
| Jump to the waiting session | No. Clicking usually opens Script Editor. | Click Mori to open the session |
| Timing for each step | No | Execution waterfall with tool calls, approval waits, and exit codes |
| History | No | Stored on your Mac until you delete it |
| Cost and setup | Free. Edit config files. | Native Mac app. Early access. |
Coverage in MoriBlink depends on the agent. OpenCode has live observation. Claude Code and Codex are hook previews, so their sessions appear in History without live timers or completion alerts.
See every agent in one place
MoriBlink is a native Mac app for people who run coding agents. It follows every session, tells you the moment one needs you, and shows where a slow run spent its time.
Get early accessQuestions
How do I know which coding agent is waiting for me?
Add the project name to each agent's notification command, or use a tool that lists every session in one place. MoriBlink shows each connected session and its state, and Mori appears when one needs approval or an answer.
Why is my coding agent so slow?
Split the turn into its steps. Common causes are time spent waiting for your approval, long builds or test runs, and repeated failing commands. Some time is unmeasured, so treat a timeline as a starting point, not proof of the cause.
Can I run several coding agents in the same repository?
Yes. Give each session its own git worktree, so their edits do not collide, and its own terminal tab named after its task.