Abort, Pause, Resume, Steer, Delete

TL;DR

Pause an attempt when you want work to stop for now without abandoning it, then Resume when you're ready to continue. Zozo preserves the accepted objective and recorded progress across recovery. On a dispatched Issue, Steer sends a question or correction at the next safe boundary when the Provider supports it. Interrupt and continue is the explicit alternative for other Providers. Both continue on the same Thread with your message, while Abort abandons the attempt and Delete removes an idle or paused one, returning its unresolved Issue to ready-for-agent.

Open an attempt's actions in the Dashboard, then choose the control based on what you want to happen next. How Dispatch Decides explains how work is picked. This page explains the controls you can use after work has started.

Keep an Issue Out of Zozo Entirely

Apply not-for-agent in GitHub when an Issue is human-owned work that Zozo must behave as though it doesn't exist. Zozo won't pick or promote it, show it on Needs Attention, or include it in a Project panel. Record the reason in the Issue body because the label states only the exclusion.

Use Label Reference to choose the Control Label that matches the reason. In particular, needs-info means a dispatch attempt has ended and needs human review. It isn't a general waiting-for-an-answer label.

Choose the Outcome You Want

Control	Use it when	What changes
Pause	You want work on the Issue to stop for now, but you plan to continue the same attempt.	The active Run is interrupted and the attempt shows as paused. Its history and work are kept, and the Issue remains in progress until you choose Resume or Delete.
Resume	You want to continue a paused attempt. Resume is also available when an attempt shows as stuck because it no longer has an active Run.	Zozo continues the attempt with its pinned objective, recorded progress, and Workspace work. The new Run starts when capacity is available.
Steer	You want the agent to apply ordered input at the next safe boundary and its Provider supports verified delivery.	Zozo records the original message and attachment references before offering them. The message remains pending until the Runtime acknowledges delivery.
Interrupt and continue	You want the agent to answer a question or adjust its approach, then keep working toward the same Issue objective.	The current Run is interrupted immediately. A successor receives your original message separately from the pinned objective, acceptance criteria, recorded progress, and remaining allowance. It reconciles partial Workspace effects before continuing on the same Thread and attempt.
Abort	You want to stop the active Run and make the unresolved Issue available for a fresh attempt.	The Run ends as aborted, but the Thread and its history remain in the Dashboard. The Issue returns to ready-for-agent unless it has already been closed or merged.
Delete	You want to abandon an idle or paused attempt and remove its history.	Zozo deletes the Thread and all of its Runs and recorded history. The unresolved Issue returns to ready-for-agent so the Dispatcher can start a fresh attempt.

Interrupt and continue is the one control that corrects a running attempt instead of stopping it. Abort abandons the attempt outright and returns the Issue, and Pause stops the attempt without sending it a message. Reach for Interrupt and continue only when you want the same attempt to carry on with what you just told it.

The Dashboard only shows actions that are valid for the attempt's current state. An active Run offers Abort, Pause, and, when the attempt is still being followed by the Dispatcher, Interrupt and continue. A paused attempt offers Resume and Delete. An idle attempt offers Delete, with Resume added when the attempt is stuck.

Pause Now and Resume Later

Choose Pause when you don't want the current attempt to keep running, but you do want to return to it. Pausing interrupts an active Run and prevents Zozo from starting another Run on that Thread. It keeps the attempt's work and leaves the Issue's agent-in-progress label in place.

Only Resume restarts a paused attempt. When you choose it, Zozo continues the same attempt. A recovery may use a successor Thread when its original Credential is unavailable, but the accepted objective and recorded progress carry forward. If every work slot is occupied, the request waits in the queue and the attempt continues to show as paused until a slot is available. A resumed Thread keeps its selected Credential, model, and effort; tuning edits apply to new Threads.

A deployment never resumes stopped work automatically. Explicit Resume preserves the attempt's Workspace, Thread history, accepted objective, and recorded progress, then applies the current completion-declaration rules. An older or malformed completion report won't create a new Run solely to rewrite that report.

Zozo pins the Issue title, body, acceptance criteria, and a content-addressed revision when the attempt starts. The Thread Detail view shows that active objective revision. Editing the Issue later doesn't silently change work already in progress: adopting a later edit as the active objective always requires the same explicit confirmation a Steer's proposed revision does (see Resolve an Objective Conflict below). Once an attempt has more than one revision, Thread Detail also lists its full history: each prior revision shows as superseded, abandoned, or completed, so you can tell which objective a given change actually served.

Don't rely on a later Issue edit during recovery

Recovery restores the pinned objective and progress recorded in the Event journal. For an older attempt created before objective pinning, Zozo marks the revision as unknown and doesn't substitute the current Issue text. Review the Workspace and recorded progress, then provide clarification if needed.

Once work starts, Zozo makes 2 attempts by default to recover the attempt. The result determines what you see next:

• When the resumed work succeeds, Zozo removes agent-in-progress. If its Pull Request needs attention before it can merge, Zozo adds landing-blocked.
• When both recovery attempts fail, Zozo removes agent-in-progress, adds needs-info, and leaves the Issue for you to review.
• When the Runtime is unavailable, Zozo keeps the Issue in progress so it can try again after the Runtime recovers.

Interrupt and Continue a Running Attempt

When a Provider supports verified safe-boundary delivery, choose Steer. Zozo accepts each message durably before delivery and shows it as pending until the Runtime acknowledges it. Several messages keep their acceptance order and may be delivered as one batch. A later instruction supersedes an earlier conflicting instruction within the accepted objective. An instruction that conflicts with the accepted objective or its acceptance criteria requires clarification instead of a silent resolution; see Resolve an Objective Conflict below.

Delivery acknowledgment confirms that the Runtime received the message. It doesn't mean the requested work is complete. A pending message prevents the attempt from reporting success or advancing to a Pull Request. If success was recorded first, Zozo discloses that state and records the new message as a follow-up.

Resolve uncertain delivery before consequential work

After a restart, Zozo surfaces any delivery whose offer was recorded without a known acknowledgment. Reconcile that state before repeating an action with external effects. Pause keeps accepted messages pending; Resume applies them before the agent's next action.

Choose Interrupt and continue when you want the agent to handle a question or correction and then finish the accepted objective, instead of stopping the attempt the way Abort does or pausing it without a message the way Pause does. Send it from the Thread Detail view for a running dispatched Issue.

The Claude Provider delivers a Steer through its persistent Runtime input channel. It waits for every tool in an in-flight parallel batch, offers the ordered message before Claude's next model request or tool action, and keeps the message pending until Claude acknowledges the matching delivery. Permission checks, the selected Credential, normalized Events, native session replay, usage-cap handling, and the Runtime-owned agentic loop remain unchanged.

The OpenCode Provider establishes the same safe-boundary contract at a different point: Zozo accepts your message durably right away, then delivers its exact text as the next Run's prompt once the current turn finishes on its own account, never interrupting it. The message stays pending until that next Run reaches the Runtime, and the successor still carries the accepted objective, recorded progress, and remaining allowance forward.

Codex uses Interrupt and continue because its pinned Runtime can acknowledge that its transport accepted a message, but doesn't guarantee a gate after all parallel in-flight actions and before the next action. Other Providers without verified safe-boundary delivery use the same path. The Dashboard labels this action as an immediate interruption and shows the Provider's concrete limitation before you submit it. Zozo preserves your message as Human Input, restores the pinned objective and acceptance criteria from the attempt, includes journal-backed progress and the remaining cumulative allowance, and tells the successor to handle the detour before continuing. In-progress file changes or commits may be partial, so the successor reconciles the Workspace before repeating an action with external effects.

Reconcile a lost Claude acknowledgment

If Claude's input channel fails after Zozo offers a message but before the matching Runtime acknowledgment, the Dashboard marks delivery uncertain. Zozo doesn't silently switch to interruption or redeliver consequential input.

The Issue stays in progress and its agent-in-progress label is untouched. The successor keeps the same Thread, admission slot, and Lease. Your message appears in the Human input section of the Issue and its Pull Request, alongside any Clarification answers.

Afterward, the interrupted Run shows as steered and the new Run streams in below it on the same Thread. If the Run had already finished on its own before your message arrived, Zozo sends it as an ordinary reply instead and tells you so, since there was no longer a turn left to interrupt.

Interrupt and continue is hidden or disabled in three cases:

• While the attempt is still queued waiting for capacity, since there's no running turn yet to redirect.
• On a paused Thread. Choose Resume first, then Interrupt and continue the resumed attempt.
• When the attempt isn't currently being followed by the Dispatcher. Abort it and resume it to steer again.

Redirect an Intake, Clarification, or Wayfinder Ticket Session

An Intake Session, a Clarification reply, and a Wayfinder grilling Ticket each keep their composer enabled while a turn is running, the same way a dispatched Issue attempt does. Sending while a turn runs redirects it instead of queuing behind it, labeled Steer. Delivery uses the session's verified safe-boundary channel when its Provider supports it, or interrupts the running turn otherwise. Either way, Zozo records your message durably first and shows its delivery state (pending, delivered, or uncertain) instead of guessing.

Each session keeps its own resolution rules. Redirecting an Intake Session doesn't move it to Planning, confirm its Issue Plan, or Publish it. A Clarification reply resolves when the agent declares its understanding in a valid clarification-resolved block. The Dispatcher records the answers and Declared Understanding, then resumes the same Thread under normal dispatch admission. A plain or malformed reply stays parked with its message for you to answer again. Redirecting a Wayfinder Ticket doesn't resolve it; resolution stays a separate action you choose explicitly. After Clarification resolves, its view redirects to the Thread. Later messages are Steers recorded as Human Input, and Abandon is no longer offered.

A restart doesn't drop a message sent mid-turn

If Zozo restarts between accepting your message and delivering it, the session doesn't discard it or silently treat your next message as unrelated. It resubmits the earlier message first, ahead of anything you send afterward.

Resolve an Objective Conflict

When a Steer or an Interrupt and continue message conflicts with the accepted objective or its acceptance criteria, Zozo pauses implementation instead of guessing. It parks the attempt the same way a missing-information Clarification does, and shows the conflicting instruction alongside a proposed revised objective in the Clarification session view.

You have three ways to resolve it:

• Reply to keep the accepted objective unchanged. Answer like any other Clarification. The objective conflict stays parked for your decision; a declared understanding alone cannot resume it or revise the objective.
• Adopt the proposed revision. Add a short confirmation explaining the decision and choose Adopt this revision. Zozo records the confirmation as Human Input, replaces the accepted objective with the revised title and acceptance criteria, and records the prior objective as superseded, not discarded. Implementation resumes on the same Thread under the revised objective.
• Abandon the conflict. The Issue moves back to needs-info for you to decide next steps. Unlike abandoning a plain Clarification, this preserves the attempt's Thread, Workspace changes, and recorded history rather than releasing them.

Adopting a revision never replenishes consumed allowance

The objective allowance already spent carries forward unchanged across a revision. Increasing it remains the separate explicit action described in How Dispatch Decides.

Unrelated replacement work always needs its own Issue and Thread. Adopting a revision only ever changes the objective on this attempt's existing Thread; it never reassigns the attempt to a different Issue or publishes a new one on your behalf.

Abort a Run or Delete an Attempt

Choose Abort while a Run is active. Zozo stops that execution, keeps the Thread's history for reference, and returns an unresolved Issue to ready-for-agent. You can review the stopped attempt in the Dashboard while the Dispatcher is free to start a fresh one.

Choose Delete when no Run is active and you no longer need the attempt or its history. Deleting removes the whole Thread, including every Run and recorded history it contains. For an unresolved Issue, it also replaces agent-in-progress with ready-for-agent. A closed or merged Issue isn't made ready again.

Protect Unshipped Work

An Unshipped Attempt is marked unshipped because it has commits that haven't reached a Pull Request. The Dashboard warns you before an action would discard the only copy of those commits. The Dashboard doesn't provide access to the code in that attempt, so the warning is your choice between preserving the attempt and discarding its work.

Continue with Delete only when you're willing to discard that work. If an Abort stops the Run but Zozo then discovers unshipped commits, it keeps the Issue in progress and preserves the attempt. You can leave the attempt in place, or use the Delete confirmation to discard it and return the unresolved Issue to ready-for-agent.

Related

• How Dispatch Decides: how an Issue is selected and who receives the next work slot.
• Label Reference: what the labels shown in the Dashboard mean.
• Work Model: why Resume may wait for capacity.