Use the Console

Cori Console is the desktop app for running the workflows on your own machine. Install it once, open it from your menu bar / system tray, and run, watch, and inspect your workflows without touching a terminal.

It's the everyday surface on top of the same engine the Cori command-line tool drives. The CLI and the Cori agent skill remain the authoring and power-user paths.

Install

Download the installer for your platform from cori.do — the download button picks the right build for your OS and CPU — or from the releases page:

• macOS — Cori.dmg (Apple Silicon or Intel). Drag into Applications, then open.
• Windows — Cori.msi. Double-click and follow the installer.
• Linux — Cori.AppImage (executable bundle) or Cori.deb (Debian / Ubuntu).

The first launch may take a few seconds while Cori prepares its local engine. After that, opening the app from the menu bar / system tray is instant.

The app also bundles the cori command-line tool. If cori isn't already on your PATH, an Install CLI button appears in the launcher's footer — one click links the bundled CLI into place, so terminals and coding agents can use it too. See the CLI reference for what it can do.

Living in the tray

The app lives in your system tray (macOS menu bar, Windows tray, Linux indicator).

• Left-click the tray icon to toggle the launcher — open + focus if it's hidden, hide if it's already in front.
• Right-click the tray icon (or the platform's equivalent gesture) for the menu:
  • Open launcher — same as a left-click.
  • History… / Schedules… / Workers… — open the manage window straight to that tab.
  • Quit Cori — the only real exit. Until you choose this, scheduled workflows keep firing in the background.
• Closing the launcher window hides it to the tray — the engine keeps running and schedules keep firing. Use Quit Cori when you want everything to stop.

The launcher

The launcher is the small window the tray toggles. From top to bottom:

Search bar

One row with three things:

• The input. Start typing immediately — the launcher is already focused.
• An interpretation chip (appears once you've typed something) — tells you what Enter will do next:
  • filter — keeps narrowing the items shown below.
  • local folder — opens the folder you've typed.
  • remote — fetches the workflows in the repository you've named (e.g. github.com/acme/flows, or just acme/flows for the GitHub shorthand).
• A folder icon at the right — click to open a local-browse view at your last-visited folder.

Two things to remember:

• Typing filters the list. Instant, in-memory. The launcher never reaches across the network on a keystroke.
• Enter changes what you're browsing. A path opens a folder; a repository reference fetches and lists that repo's workflows.

Breadcrumb

A line just above the results that names where you are: Recents by default; the folder path when you've drilled into a local folder; the repository + version + short pinned commit when you've opened a remote repo.

When you're in a remote repo, a small refresh icon at the right of the breadcrumb checks the remote for a newer version of the reference you're following and re-fetches if it's moved.

Results

The list under the breadcrumb. Use the keyboard:

• ↑ ↓ — move the selection.
• Enter — open whatever's selected (a workflow opens its launch window; a folder drills into it).
• → — drill into the highlighted folder.
• Esc or Backspace on an empty input — go back one level (e.g. local → recents).
• ⌘L / Ctrl-L — re-focus the search bar from anywhere.

Recents show the workflow's friendly name, with the status of its last run + when it last ran + the path or repository on the second line. If you can't run a recent any more (the folder moved, a cached repository was cleared), the row is greyed out with a tooltip explaining why.

Footer

A small status badge on the left — Ready when the engine is up; Starting… while it boots; Degraded or Offline when something's wrong. Two buttons on the right open the manage window: History and Schedules. Workers is one click further away (inside that window, or from the tray menu).

If the cori command isn't on your PATH yet, an Install CLI button also appears here — one click puts the bundled CLI on your PATH and it disappears once installed.

Drop a folder onto the launcher

You can drag any folder from Finder / Explorer / your file manager onto the launcher window:

• A workflow folder → opens its launch window directly.
• Any other folder → lands you in the local-browse view at that folder.

A dashed outline and a "Drop folder to open" hint appear while you're hovering. Dropping a file (or something Cori can't read) is ignored quietly.

The launch window

Opens when you pick a workflow — from a recent, a local folder, a remote repository, or a drop. One launch window per workflow.

Inside you'll see:

• A summary of the workflow.
• A parameters form, generated from the workflow's manifest. Text fields, numbers, checkboxes, drop-downs, paths — whatever the workflow declared, you fill in here.
• Warnings, if any — a missing tool you need to install, a credential you need to sign in to, or a step kind that isn't supported yet.
• A Dry run toggle to validate the plan without actually executing.

Click Run workflow (or Validate if dry-run is on). The window spawns a run window and closes itself.

The first time you run a workflow from a remote repository, a trust prompt appears with the repository, the exact version, and the capabilities it'll use. You only have to confirm this once per (repository, version).

The run window

One window per run. It shows the workflow stepping through in real time — each step lights up as it starts, then settles into success / failure with the time it took.

When the run finishes, the window stays open with the full trace — every step, with its inputs, outputs, errors, and per-step cost when available. You can re-open the same run later (from History in the manage window) and you'll be looking at the same view.

If you close a run window mid-run, the run keeps going — only the view is dismissed. The next time you open it, Cori re-attaches and shows you everything you missed.

The manage window

A single window with three tabs.

• History — every run that's happened on this machine, newest first. Filter to one workflow, click a row to open its full trace in a run window. Same data the command-line tool can show.
• Schedules — workflows that fire on a cron. Click New schedule to register one (the cron and timezone fall back to whatever the workflow's manifest declared if you leave the fields blank). Each entry shows when it'll fire next, how the last fire went, and an Enable / Disable button. A schedule is owned by the identity that created it; only that identity's running app or worker will fire it.
• Workers — every Cori worker visible from this machine. Your own machine is badged so you can tell it apart. This is mostly a diagnostic surface — you typically only visit it when something's not running where you expect.

The launcher footer's History and Schedules buttons, and the matching items in the tray menu, each open this window straight to the corresponding tab. If the window is already open on a different tab, it switches to the one you asked for.

Working with workflows hosted in a git repository

Type a host/owner/repo reference (or just acme/flows for the GitHub shorthand) and press Enter. Cori fetches the repository, locks it to a specific version, caches it locally, and lists every workflow inside. You can then pick one and run it just like a local workflow.

A few things to know:

• The version is pinned the first time you resolve it. You'll keep using that exact version until you choose to advance — which you can do by clicking the refresh icon in the breadcrumb. That checks the remote for the latest matching version and re-fetches if it's moved.
• Browsing a repository grants no permissions. You only consent to a workflow's capabilities when you run it for the first time, in the launch window.
• Private repositories use whatever credentials your git already uses on this machine — SSH keys, credential helpers, the usual. Cori doesn't collect or store credentials. If something isn't reachable, the message you see is the same one git would print directly.

What the Console does not do

• No accounts, no multi-user, no permissions plane. Single OS user, local only.
• No remote access. Nothing listens on a network port, no web UI, no shared state.
• No authoring. The Console reads and triggers workflows. To write or edit one, use the Cori agent skill or your editor — Cori never writes into your workflow folders.
• No cost dashboards. A workflow's run trace can record per-step cost when its steps produce it, and you'll see that in the run window — but there's no aggregate analytics product.
• No cross-repository search. You browse one folder or one repository at a time. There's no registry or marketplace.

---

For developers contributing to the Console itself, see the project repository's console/README.md.