---
title: "Answer blocked runs in the web app"
date: "2026-05-02"
---

## Interview dock for blocked runs

Blocked runs can now be answered directly from the run page. The new interview dock supports yes/no, confirmation, multiple choice, multi-select, and freeform questions, including write-in responses when a choice question allows them.

The dock listens to interview events and refreshes as questions arrive, so a parallel workflow with multiple pending prompts can be drained from one place. Cancelling the run stays in the page header while the dock stays focused on the current question.

## Principal attribution and auth routing

Run events and run creation now carry clearer principal information for users, workers, systems, Slack interactions, webhooks, and agents. API clients get explicit provenance objects instead of older actor-shaped fields that could lose where a run came from.

This also closes attribution gaps across web, CLI, worker-token, Slack, and human-interview paths. Runs created or advanced through different surfaces now preserve who or what took the action more consistently.

## More

<Accordion title="API">
- Run specs now include client and server provenance shapes
- Run events use unified principal shapes for user, worker, system, Slack, webhook, and agent subjects
</Accordion>

<Accordion title="CLI">
- Bounded server readiness probes so startup and status checks fail promptly instead of waiting indefinitely
</Accordion>

<Accordion title="Fixes">
- Fixed principal attribution gaps during run creation and interview callbacks
- Fixed auth routing regressions around worker tokens and human-in-the-loop callbacks
- Preserved remaining error context in provider auth, tracker, OAuth, graph rendering, and workflow command errors
</Accordion>
