A Local-First Multi-Agent Dashboard for Codex CLI and Claude Code

volition79 — Sun, 19 Apr 2026 12:37:18 +0000

If you use Codex CLI or Claude Code for real work, you’ve probably run into the same problem I did: once a task gets bigger, it becomes hard to see the overall plan, review it before execution, and
keep track of what each sub-agent is doing.

That is why I built Sonol Multi Agent.

It is a local-first multi-agent setup that turns a single request into a structured plan, lets you review and approve that plan in a UI dashboard, and then shows the sub-agent flow and runtime progress while
the work is happening.

This project is for people who want a more visible and controllable multi-agent workflow without handing the source of truth over to a browser tab or a remote web app.

Project link: https://github.com/volition79/sonol-multi-agent

## What you get

With Sonol Multi Agent, you can:

turn one request into a structured multi-agent plan
review and approve that plan in a dashboard before execution
monitor sub-agent flow and runtime progress
keep orchestration state local instead of making the browser the authority

The goal is not just to make multi-agent workflows possible. It is to make them easier to follow, easier to trust, and easier to recover when something goes wrong.

## How it is set up

The system is split into two skills, and both need to be installed together:

sonol-multi-agent
This handles planning, proposal flow, approval flow, and orchestration.
sonol-agent-runtime
This handles runtime reporting, bridge-connected dashboard updates, and shared execution state.

If you install the repo and follow the README, you can use the two skills together as one workflow.

## Why I built it this way

A lot of multi-agent systems are cloud-first.

The planner owns the state, the dashboard owns the state, and after a while the browser session starts to feel more important than the machine actually doing the work.

I wanted the opposite.

In this setup:

the local AI session creates the first creative draft
a hosted planner only normalizes and binds that draft
the local SQLite database remains authoritative
the local bridge remains authoritative for dashboard and runtime access
the remote dashboard stays a thin UI layer

That boundary matters a lot to me. I did not want browser storage or a remote dashboard to quietly become the real source of truth.

## Why local-first matters in practice

This is not just a philosophy choice.

It affects how the system behaves when something is messy in the real world.

When orchestration state stays local, it is easier to understand:

what the current plan actually is
whether approval really happened
which run is active
what events were emitted
what the local runtime believes right now

That makes debugging, recovery, and trust much better than when state is scattered across a browser session and remote services.

## Tested environments

So far, I have tested this setup in these environments:

Codex CLI on Windows WSL
Claude Code on Windows

I also recently tested Claude Code on macOS. The first run hit an environment-specific issue, but once the exact terminal error text was shared, the problem was fixed and the workflow behaved normally
afterward.

That process also helped tighten some of the practical parts of the system, including path handling, runtime behavior, and recovery.

## If you want to try it

If this sounds useful, I’d encourage you to download the repo, install both skills, and try it on a real task.

If you do, I’d especially like feedback on:

the installation flow
the approval and dashboard experience
local-first orchestration tradeoffs
failure recovery during multi-agent runs

That kind of feedback is much more useful than a demo-only reaction, because the whole point of this project is to make multi-agent workflows usable in actual developer environments.

Repo: [https://github.com/volition79/sonol-multi-agent]

DEV Community: volition79

A Local-First Multi-Agent Dashboard for Codex CLI and Claude Code