A work order goes out. Evidence comes back.

01 / GETTING STARTED

The plugin routes work. Everything else is optional.

Worker Routing is an instruction-only plugin: it creates no models, stores no API keys, and does not implement the Codex multi-agent runtime. It gives your main agent rules for when to delegate, what to hand over, and how to return the result. You can start with native Codex workers.

• Ask Codex’s built-in plugin-creator to register plugins/worker-routing into your personal marketplace, keeping your current model and provider.
• Then open a new main session to confirm it loaded: registration is not activation.
• It only changes future routing: no request is taken over, no model or paid route chosen for you. The ACP route and main-session context integration are separate optional additions.

Full repository reference ↗

02 / DELEGATION & ACCEPTANCE

Hand over a whole responsibility, not a command.

Delegate a responsibility that can finish on its own: investigation, change and self-check for one worker. A work order names the outcome, boundaries and what to return; small or nearly finished tasks can stay with the main agent.

Fix the CSV import failure caused by blank rows.
Scope: one function plus one focused check.
Add a check that reproduces the bug, run it, and return the diff and result.
Do not touch the public API or unrelated files.
Stop and report if the fix would cross that boundary.

• For a correction, continue the same session, not a new worker.
• Before delivery the main agent reviews the diff and checks. “Done” from a worker is a claim, not acceptance.
• Say “solo” or “do not delegate” to keep the work in the main session; the main agent should also avoid re-implementing work already delegated.

Full repository reference ↗

03 / OPTIONAL ACP ROUTE

An external route is optional.

Start with one default worker, without comparing models or writing capability profiles. Native workers use host tools; a registered ACP route can also be your everyday default with its own separate session.

• Route config, worker home, workspace allowlist and provider/account choices stay outside Git, under your control.
• Set routing.default in the existing ACP config and omit --route on ordinary runs. Change channels in that one place; routing.fallbacks may stay empty and backups require prior authorization.
• Automatic backups handle only unavailable entries or missing required environment credentials before launch. After startup, recover the original execution first. Changing the default preserves existing sessions; disabling a channel blocks further continuation.
• The work order goes to your configured agent. --permissions read|full only decides how cwr-acp answers ACP permission requests; it is not an OS sandbox and gives no isolation.
• A route starting or a model listed does not prove real inference succeeds; initialization and execution are separate.

Full repository reference ↗

04 / LOCAL DISPATCH

Receipts leave a trail.

Dispatch displays local ACP receipts and review notes you add on purpose. Business data is read-only; theme, language and timezone can be saved. It schedules nothing and adds no second job database. Native Codex activity has no data source here: every metric is ACP-only.

node integrations/acpx/src/cli.mjs dashboard --config /absolute/private/config.json
node integrations/acpx/src/cli.mjs stats --config /absolute/private/config.json --since 7d

• The command runs in the foreground and prints a private loopback URL (ephemeral port by default); open that URL yourself and keep the process running. Before your first ACP task the panel opens empty, which is expected.
• Accounting: runtime completion is not acceptance; observed tokens are known workload, not quota saved and not billing evidence; missing data stays unknown.
• Projects come from the working directory: Git repositories group linked worktrees, with a folder filter. These are not saved Codex project names; no chat text infers identity.
• Usage coverage states how many tasks have attributable data; ordinary completion needs no annotation or to-do.

Full repository reference ↗

05 / SHARE CARDS & PRIVACY

A little card that stays yours.

Share cards preview 1600×900 landscape and 1080×1350 portrait, as SVG or PNG. Theme, language and layout are independent: four themes × two languages × two layouts × SVG/PNG give 32 combinations, named with theme, language, format and date.

• Share cards open from the “Share card” button in the dashboard header.
• Numerals offer Soft / Book / Mono, ornaments Thread / Bloom / None; decorations stay in local SVG.
• The slogan starts from four bilingual presets and is editable; an optional shared-by credit is separate. Both are text you enter, escaped as plain text, never inferred from records.
• The statistics portion accepts only aggregate totals, period, timezone and coverage. Work orders, outputs, private route names, paths and internal IDs are never filled in automatically, and nothing auto-uploads.

Full repository reference ↗

06 / CONTEXT & BOUNDARIES

An input boundary, not a filesystem sandbox.

The optional main-session integration uses a native SessionStart hook to load your private instructions before the first root request, into the root only; new workers do not inherit the main conversation. Main context must arrive before that first request for new work to keep the root/child boundary.

• The hook applies to the root only and must be reviewed and trusted by you; the installer does not rewrite AGENTS, auto-approve hooks or change model/provider config.
• Host-shared engineering rules may still reach workers — “shared rules” is not limiting file access to one directory; route config alone provides no isolation.
• File permissions come from the host sandbox; this does not stop a process with file tools reading other local files.

Full repository reference ↗