STUPID-2026-0081

Aider exits with code 0 after a fatal API connection failure, masking hard failures as successful headless runs

4.8medium
August 11, 2026VerifiedReproducible

  1. Instruction given

    None specific to a coding task — the failure occurs at connection time, before Aider reaches any user instruction, when it is invoked headlessly with `--message` against a malformed or unreachable API endpoint (e.g. `AIDER_OPENAI_API_BASE="https://invalid-url" aider --message "test"`).

  2. Expected behavior

    When Aider cannot reach the configured API after exhausting its retries, it should exit with a non-zero status code so that any CI job, cron invocation, or orchestration layer gating on the exit code correctly detects the run as failed.

  3. Actual behavior

    Aider catches the underlying litellm connection exception, retries up to its maximum retry count, logs the failure to its own output, and then exits cleanly with code 0 — the same code it uses for a successful run. A caller that only checks the process exit status has no way to distinguish this from a normal, completed invocation.

  4. Damage

    Filed by the affected user (noelsaw1) with an exact reproduction command and no maintainer response yet as of publication. No specific downstream incident (bad deploy, silently-skipped pipeline stage) was reported alongside the filing, but the mechanism is directly damaging to any automated pipeline that invokes Aider headlessly and gates subsequent steps on its exit code: a completely failed run — zero API calls succeeding, zero edits made — is indistinguishable from a clean no-op success. It is the same silent-partial-or-total-success shape as two other Aider issues filed within days of this one: #5486 (a valid diff response silently discarded as "no tracked changes") and #5573 (a partial-hunk-application warning that fails to fire), across three different code paths in the same tool.

An Aider user running the tool headlessly for automation found that a fatal API connection failure — an invalid base URL or malformed credentials — does not produce a failed process. Aider's own retry logic catches the `litellm` exception, retries until it exhausts its retry budget, logs the failure, and then exits with code `0`, the same status a successful run reports. The behavior reproduces directly: pointing `AIDER_OPENAI_API_BASE` at an unreachable host and invoking `aider --message "test"` retries, fails every attempt, and still returns exit code 0. Any CI job, cron wrapper, or orchestration layer that gates its next step on Aider's exit status — the standard way headless tools report success or failure — reads a total connection failure as a successful, work-free run. No maintainer response had landed as of this writing. It is the third distinct report within the same week of an Aider code path silently swallowing a failure signal that should have reached the user or caller, following separate issues in edit-format auto-selection (#5486) and unified-diff partial-application warnings (#5573) — different functions, same shape: the tool fails, and nothing downstream is told.

Classification

Agent
Aider
Failure mode
Logic Error
Root cause
Logic Error
Domain
Infra
Source
Github Issue

Related incidents

8.4
Amazon AI coding agent mistake blamed on human employees
5.8
Cline's tool-call JSON repair silently executed truncated write_file and terminal arguments as valid
4.4
The quiet correctness tax: 43% of AI code changes need production debugging, with up to 75% more logic errors
4.4
OpenAI's Operator scored 38% on real computer tasks — and panics instead of recovering from errors
Discuss on Hacker News

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.