Our Aider review lists "works on remote servers or headless environments where GUI editors are not an option" as a reason to pick it, and mentions "CI scripting" as one of the things people pair it with alongside Cursor. That's a claim about non-interactive, unattended use — so this week we checked it against Aider's own open issue tracker instead of just our own six months of interactive terminal use.
Two open bugs specifically undercut it.
Aider can exit 0 after a fatal failure. Issue #5552: if the configured API base URL or auth token is bad, Aider retries, logs the failure, and then exits with status code 0 — the same code it uses for a clean, successful run. A CI step or automation script that checks the exit code to decide whether anything happened will read a hard failure as "ran fine, touched nothing." That's the specific failure mode that makes exit codes worth having in the first place, and it's inverted here.
Aider can crash before it even starts. Issue #5499: on a system without an existing .aider.conf.yml, Aider (0.86.2) throws an uncaught FileNotFoundError out of configargparse.py during argument parsing — before your prompt is ever sent. No graceful "no config found, using defaults," just a raw traceback. In a headless provisioning script that assumes a fresh environment, that's a hard stop with no clear signal why.
Neither issue has a assignee or an open PR as of this week. Neither is about diff quality or model output — they're both about the boring, load-bearing part of running a CLI tool unattended: does it tell you honestly when it failed.
We're not walking back the review's core take — Aider's Git-native workflow is still the best in its category, and interactive terminal use is where we've spent almost all our six months with it. But "headless environments" and "CI scripting" are specific claims, and right now they come with caveats our page doesn't mention. We're correcting that.
Full review: https://devtoolsreview.com/reviews/aider-review/
Top comments (0)