Aider silently discards a model's correct diff response as "no tracked changes" when it guesses the wrong edit format

1. Instruction given

   None specific to this bug — the user was working normally in a large (~1,100-file, ~179k-token context) repository with a model (qwen3.8-max-preview via an OpenAI-compatible endpoint) that has no entry in Aider's model-settings.yml, so Aider auto-selected the `whole` edit format rather than being told which format to expect.

2. Expected behavior

   When the model's response doesn't match the edit format Aider expects, and in particular when it takes the form of a well-formed unified diff instead of a `whole`-format rewrite, Aider should either parse it as a diff anyway or clearly warn the user that a response was rejected for a format mismatch — not discard it silently.

3. Actual behavior

   The model ignored the auto-selected `whole` format and returned a standard unified diff containing correct, well-reasoned code changes. Aider's parser could not match the diff against the `whole`-format parsing path, concluded there were no tracked changes, and discarded the entire response with no warning or error. The user saw only an empty, no-op turn; nothing indicated the model had actually done the work and Aider had thrown it away. Setting `--edit-format diff` explicitly avoided the bug.

4. Damage

   Filed by the affected user (noelsaw1) with an exact reproduction: use a model absent from model-settings.yml so Aider auto-selects `whole` format, then have the model respond with a unified diff instead. No maintainer response or fix had landed as of this write-up. No specific production incident was reported alongside the filing, but the failure is silent by construction — a user has no on-screen signal that their turn produced real, correct work that was then discarded, and may re-prompt, assume the model failed, or lose the change entirely. It is the same silent-partial-or-total-success shape as two other Aider issues filed within roughly the same window: #5573 (a partial-hunk-application warning that fails to fire, STUPID-2026-0080) and #5552 (headless mode exiting 0 after a fatal API failure, STUPID-2026-0081) — a third distinct code path in the same tool where work is lost or a failure occurs with nothing surfaced to the user or caller.

Classification

Agent

Aider

Failure mode

Logic Error

Root cause

Logic Error

Domain

Backend

Source

Github Issue