Action Center

Live work, decisions, failures, and builds waiting to run.

The Action Center is the home screen at /dashboard/action-center. It is a single queue built from four different resource types — AI Plans, AI Sessions, iOS builds, and workflow runs — so anything that is running, stuck, failed, or waiting on you shows up in one list instead of five separate pages.

Nothing is added by hand. The control plane derives the list from the current state of each resource, so an item disappears on its own as soon as the underlying work moves on.

Page URLs and breadcrumbs

Web page URLs follow the sidebar section: /dashboard/..., /ai/..., /debugging/..., /github/..., /gitlab/..., /jira/..., and /system/.... For example, open /github/pull-requests for GitHub Pull Requests or /system/settings for Settings.

These paths omit the locale prefix. An English URL starts with /en, such as /en/dashboard/action-center. Opening the site root or a locale root takes you to the Action Center. Previous URLs for moved pages have no redirects; update saved bookmarks and shared links.

The title-bar breadcrumb shows the section and page, such as GitHub → Pull Requests or GitLab → Cache. GitHub and GitLab page headings include the provider name, while the sidebar and breadcrumbs keep their shorter labels. The /api/... endpoints and /graphql subscription URL keep their existing paths.

What appears here

An item is a resource plus the reason it earned a place in the queue.

Plan

A read-only codebase survey. Appears while it is Queued, In progress, or Paused, and after it fails.

Session

An AI run that edits a worktree. Same rule as Plans — queued, in progress, paused, or failed.

Build

An iOS build that is queued, preparing, running, or failed — plus successful builds that have never been run on a device.

Workflow

A workflow run that is queued, running, pausing, paused, waiting, blocked, or failed.

Archived Plans, Sessions, and workflow runs are excluded entirely.

Why an item appears

Every item carries one reason badge. The reason also sets the item’s position — the list is sorted by reason first, then by most recently updated.

Reason	Badge	Meaning
Answer needed	Amber	A pending question batch is waiting on your input.
Blocked	Neutral	A workflow run is blocked, or a Plan or Session landed in a failed phase.
Failed	Red	The resource finished in a failed state and has not been acknowledged.
Ready to run	Blue	A successful build produced a runnable app that has never been deployed.
Active	Green	Work is queued or in progress and needs nothing from you.

The first four are grouped under Needs attention. Only Active items land in the Active section.

How “Blocked” is decided

For a workflow run, Blocked simply means the run’s status is BLOCKED.

For a Plan or Session, the status is still in progress but its phase ended in a failure — any phase whose name ends in _FAILED, plus the special IMPORTED_ACTIVE_COLLISION phase, which means an imported run collided with one that was already active.

How “Ready to run” is decided

A build is offered as ready to run only when every one of these holds:

• It is the most recent build for its worktree, configuration, and destination combination.
• Its status is Succeeded.
• Its worktree is still present on disk and marked available.
• It produced a runnable app artifact.
• It has no deployment records — nobody has installed or run it yet.

Run it straight from the card. The detailed picker starts on the build agent, can switch to another eligible Mac, shows compatible available and unavailable destinations, supports search and checkbox multi-selection, and includes a per-device quick-run button. A cross-agent run transfers the app through the authenticated artifact relay.

Dismiss hides this particular unrun build without marking it as deployed. The server accepts dismissal only while it is still the newest successful, runnable, undeployed build for its worktree, configuration, and destination.

The dismissal fingerprint includes the build ID. A newer successful build gets a different fingerprint and appears again.

How a failure is tracked

Each failed item gets a failure fingerprint built from its kind, id, generation, and the time it finished. Acknowledging stores that fingerprint and hides the item.

Because the finish time is part of the fingerprint, a later failure of the same resource produces a new fingerprint and reappears. Acknowledging never suppresses a future failure.

Using the page

1. Scan the counters

   Three badges under the title show the total item count, how many need attention, and how many are active. They reflect the whole queue, not just the page you have loaded.

2. Work the Needs attention section

   Items are already ordered by urgency — questions first, then blocked, failed, and ready-to-run. Each card links to the full Plan, Session, build, or run.

3. Answer any questions inline

   Pick from the offered options, or type a Custom answer when the question allows one, then Submit answer. See below for the details.

4. Acknowledge failures you have handled

   Acknowledge clears a failed item from the queue without touching the underlying resource.

5. Dismiss an unrun build

   Dismiss removes a ready-to-run build from the full or compact Action Center. The UI removes it immediately and refreshes the counters; a stale dismissal is rejected if the build stopped being the current eligible candidate.

6. Page through the rest

   The list loads 50 items at a time. Load more appends the next page.

Answering a question

Question batches come from Plans and Sessions directly, and from workflow runs by way of the step attempt that raised them — the card labels the source as Question from ….

• Single choice questions render as radio options. Picking an option clears any custom text you typed, and typing custom text clears the selection.
• Multiple choice questions render as checkboxes, and a custom answer is appended alongside whatever you checked.
• Custom answer is only offered when the question permits it.
• Submit answer stays disabled until every question in the batch has either a selection or non-empty custom text.

Answers are submitted for the whole batch at once. If a batch asks three questions, all three must be answered before you can submit.

Mini Action Center

The app shell carries a compact copy of the same queue in the sidebar, showing the total count and a condensed row per item — title, reason badge, the first pending question, any error, and the linked worktree. It shares state with the full page, so answering, acknowledging, running, or dismissing in one place updates the other immediately. The iOS list exposes Dismiss as a swipe action and repeats it on Action Center details.

Live updates

The queue subscribes to an actionCenterChanged subscription and refetches whenever the control plane signals a change. It also refetches on every reconnect, so a dropped WebSocket cannot leave stale items on screen. Refresh forces the same reload by hand.

When a Plan, Session, build, or workflow run is tied to a worktree, the card shows the worktree’s folder and branch and inherits its highlight color as a left border stripe — useful for telling parallel work on the same repository apart at a glance.

Discovery through MCP

get_action_center reads this queue with first (1–200, default 50) and an optional after cursor. It returns active work, pending questions, blocked or failed resources, and builds awaiting action. It does not acknowledge or dismiss items.

Use global_search to locate resources across the development environment. Its query is required and limited to 200 characters; firstPerGroup is 1–10 (default 5) and relatedFirst is 0–5 (default 3). Add these read-only tools to an MCP preset to help an AI find the resource it needs.

Related pages

Notifications

Route the same events to the sidebar, browser alerts, Web Push, or the iOS app.

Workflow run

Open a blocked or waiting run to repair its session data or replay a step.