coleam00/Archon · error · Error

--open and --status are mutually exclusive: the inbox is fai

Error message

--open and --status are mutually exclusive: the inbox is failed runs only.

What it means

`archon workflow inbox --open` rejects `--status` because the inbox view is, by definition, the set of failed runs; filtering by status would contradict that. The CLI throws for humans and emits a {ok:false} JSON line under --json.

Source

Thrown at packages/cli/src/commands/workflow.ts:3913

 * way `workflow run` does, then lists that project's recent runs of every
 * status. `--all` drops the project scope (lists across all projects);
 * `--status` filters to one status; `--limit` caps the count (default 20).
 */
export async function workflowRunsCommand(
  cwd: string,
  opts: { json?: boolean; all?: boolean; status?: string; limit?: number; open?: boolean } = {}
): Promise<void> {
  // Open-work inbox (#2747): terminal failed runs nothing has adopted or
  // superseded — the operator's "what ended with work on the table" query.
  // Status-derived v1 semantics; --status/--open are mutually exclusive shapes.
  if (opts.open) {
    if (opts.status) {
      const msg = '--open and --status are mutually exclusive: the inbox is failed runs only.';
      if (opts.json) {
        await writeJsonLine({ ok: false, error: msg });
        return;
      }
      throw new Error(msg);
    }
    let codebase = null;
    if (!opts.all) {
      try {
        codebase = await findCodebaseForCheckoutPath(cwd);
      } catch (error) {
        getLog().warn({ err: error as Error, cwd }, 'cli.workflow_runs_codebase_lookup_failed');
      }
    }
    const runs = await workflowDb.findOpenWorkRuns({
      codebaseId: opts.all ? undefined : (codebase?.id ?? undefined),
      limit: opts.limit ?? 20,
    });
    if (opts.json) {
      await writeJsonLine({ runs, total: runs.length, scopeFallback: !opts.all && !codebase });
      return;
    }
    if (runs.length === 0) {

View on GitHub (pinned to 0773b97458)

Solutions

Remove the --status flag when using --open; the inbox already implies status=failed.
Use `archon workflow runs --status failed` instead if you need explicit status filtering with an open workflow.
Update wrapper scripts to only forward --status to subcommands that support it.

Example fix

// before
archon workflow inbox --open --status failed
// after
archon workflow inbox --open

Defensive patterns

Strategy: validation

Validate before calling

if (args.includes('--open') && args.includes('--status')) throw new Error('drop --status when using --open');

Try / catch

try { await inbox(args); } catch (e) { if (String(e.message).includes('mutually exclusive')) { args = args.filter(a => a !== '--status'); await inbox(args); } }

Prevention

Treat `inbox --open` as already status-filtered to failed runs; never forward --status to it.
Centralize CLI flag construction in one helper so per-subcommand flag sets are explicit.
Wrap CLI invocations with --json to receive machine-readable flag errors.

When it happens

Trigger: Calling `archon workflow inbox --open --status <any status>` (or the equivalent programmatic opts combination status!=='').

Common situations: Scripts that pass a uniform --status flag to every workflow subcommand, or users copying status-filter syntax from `workflow runs` to `workflow inbox`.

Understand the failure class

Background: "mutually exclusive" flag errors: what "can't supply both nx and xx", "--raw is not compatible with -i" and "cannot be used with" mean, and how to fix them — this error's family across 29 libraries.

Related errors

AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/2150b2643e73e5e7. Report an issue: GitHub.