Skip to main content
How Risoluto manages agents from dispatch to completion.

Detection & Work Selection

Risoluto receives issue changes via Linear webhooks in real time. Polling runs as a safety net every 15 seconds by default (polling.intervalMs) — when webhooks are active, polling stretches to 2 minutes (webhook.pollingStretchMs). Candidates are filtered using tracker.activeStates and dispatched based on:
  1. Priority — higher priority issues first (lower number = higher priority)
  2. Age — oldest creation time within the same priority
  3. Identifier — alphabetical as a final tiebreaker
During startup, active issues emit lifecycle events through the SSE stream so operators can see where time is being spent:

Timeouts & Retries

For safer live proving, set codex.turnTimeoutMs to something short like 120000 (2 minutes).

Container Lifecycle

Startup

Risoluto creates a fresh per-attempt CODEX_HOME with generated config.toml, injects auth credentials, and launches the container with resource limits.

Normal Shutdown

Abort / Shutdown

OOM Detection

Exit code 137 with OOMKilled=true is surfaced as container_oom — a retryable failure. Increase codex.sandbox.resources.memory (default: 4g) if this occurs frequently.

Model Overrides

Override the model for any issue via the dashboard or API:
Model changes do not interrupt the active worker — they apply on the next run.

State Machine

Risoluto tracks issues through configurable workflow stages.
When stateMachine.stages is empty (the default), Risoluto derives stages from Linear’s workflow configuration automatically. You only need to configure stages explicitly if you want custom behavior.

What’s Next

Trust Model

Sandbox policies, credential handling, and security posture.

Configuration

Customize every timeout, limit, and behavior shown on this page.

Observability

SSE events, Prometheus metrics, and structured logs.

Troubleshooting

Diagnose OOMs, stalls, and failed deliveries.
Last modified on April 3, 2026