perform tasks

Execution tasks and issue are two different objects: an issue can be assigned repeatedly, repeatedly @mentioned, and manually rerun - each time a new execution task is generated.

graph LR
    Q["queued<br/>queued"] -->|daemon received| D["dispatched<br/>dispatched"]
    D -->|agent starts| R["running<br/>running"]
    R -->|Success| C["Complete<br/>completed"]
    R -->|error or timeout| F["failed<br/>failed"]
    Q -->|user cancels| X["cancelled<br/>cancelled"]
    D -->|User Cancel|
    R -->|user cancels| X
    F -.Retryable reason.-> Q

• queued - the task has just been created and is waiting for a daemon to pick it up
• Dispatched——The daemon process has taken it away and the corresponding AI programming tool is being started.
• Running - AI programming tools actually doing work
• completed - successfully completed, the output (comments, code submissions, status changes, etc.) is written back to the server
• failed - terminated by error or timeout; if the reason for failure can be retried, it will automatically return to queued and try again
• cancelled - user actively cancels

What happens	Timeout threshold
Delayed in starting after dispatching (the daemon took it away but did not start the AI tool)	5 minutes
Running but taking too long	2.5 hours

The failure reason for both timeouts is timeout, which will automatically retry (next section). For the associated runtime disconnection determination, see [Daemon Process and Runtime → When is the runtime determined to be offline] (/daemon-runtimes#When is the runtime determined to be offline).

The above layer is the coarse-grained bottom-up of the server - based on the task startup time, regardless of whether the task is still active. The real difference between "stuck" and "normal long tasks" is the local daemon: it no longer uses a fixed wall clock time to cut tasks (MULTICA_AGENT_TIMEOUT defaults to 0 = no upper limit), but depends on activity - as long as the agent continues to generate events (messages, tool calls), the daemon will not time out because it runs too long (the 2.5h on the server side is still the outer upper limit). Only when it is truly stuck silently will it be terminated by the Idle Watchdog (MULTICA_AGENT_IDLE_WATCHDOG, default 30 minutes); if there is no output for a long time after a tool call is issued (suspected of a stuck child process), it will be covered by a larger Tool Watchdog budget (MULTICA_AGENT_TOOL_WATCHDOG, default 2 hours). The reason for the failure of this type of task terminated by the watchdog is idle_watchdog, which is different from the wall clock timeout. For each parameter, see [Environment Variables → Adjustment Parameters of the Daemon Process] (/environment-variables#Adjustment Parameters of the Daemon Process).

Retryable (Multica automatically requeues):

• runtime_offline——After the task is dispatched, the daemon process loses contact
• runtime_recovery——The daemon process crashes and restarts to recycle the tasks that were not completed last time
• timeout——run timeout or dispatch timeout

Not Retryable (Task is stuck in failed state):

• agent_error——AI programming tool reports errors by itself (API error, quota exceeded, internal bug). The underlying issues are not retried to avoid infinite loops.

There are two additional conditions for automatic retries:

1. Maximum 2 times - 1 original task + 1 retry. If the retry fails, there will be no retry, even if the reason is retryable.
2. Only takes effect for tasks triggered by issues and chats - Tasks triggered by Autopilots are not automatically retried.

Autopilots tasks are not automatically retried by design. Autopilot has its own triggering cycle (for example, once a day); if it fails, it will automatically retry and it will overlap with the tasks of the next cycle. If you need to rerun immediately after failure, use manual rerun (next section). How do you know an Autopilot failed? A failed Autopilot task creates a notification in your Inbox, and the related issue status moves from in_progress back to todo. You can also see the latest running results of each autopilot by directly opening the Autopilots page.

multica issue rerun <issue-id>

Behavior:

• The default is to run the issue Current agent assignor - suitable for scenarios where you want rerun to follow the current assignor.
• The retry button of a certain line in the execution log will send out the task ID of this line together, and the rerun will target the original agent of that line, not the current assignee. This allows the retry button to work intuitively for squad workers, parallel @-mention agents, or old task rows that have been replaced by new assignees.
• Cancel the tasks (if any) queued/running by the target agent on this issue. Tasks of other agents on the same issue (such as parallel tasks triggered by @-mention) will not be canceled together.
• Create a brand new execution - the number of attempts is reset to 1, even if the original task has reached the maximum attempts.
• Start a brand new agent session - not inherit the previous session ID. Manual rerun means that you have determined that the last output is not good, and continuing the previous conversation will only replay the contaminated context. (Autoretry, on the other hand, inherits the session—that path handles infrastructure-level failures, not bad output.)

Comparison:

Dimensions	Automatic retry	Manual rerun
Trigger	The system automatically executes based on the failure reason	You initiate
Upper limit	2 times	No upper limit
Applicable sources	issue, chat	issues with agent assigners
Which agent to run	The original agent of the failed task	UI single-line retry: the agent of that line of tasks; CLI / without task_id: the current assignee of the issue
Session inheritance	Yes (continues last session)	No (new session)

Multica saves the session ID twice during a task: once when the task starts (when the AI tool returns the first system message), and once when the task ends, whether it succeeds or fails. The first save lets the daemon recover after a mid-task crash; the second is used for the next automatic retry, when the ID is passed back so the agent can continue from the previous conversation and file state. Manual rerun will actively skip this step and always start from a new session - see [The difference between manual rerun and automatic retry] (#The difference between manual rerun and automatic retry).

But which AI programming tools actually support it varies widely:

• ✅ True Support - Antigravity, Claude Code, Codex, Copilot, Cursor, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Pi
• ❌ Not supported - Gemini

For details, see [Providers Matrix → Session Recovery](/vibe-coding-tools/multica/providers#Who really supports session recovery).

• Providers Matrix - Comparison of the capabilities of 12 AI programming tools (including the precise status of session recovery)
• Assign issue to agent / In comments @agent / Chat / Autopilots —— Four ways to trigger task execution