You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Twice on 2026-05-16, an aetherclaude-agent PR's single commit silently reverted a recently-merged upstream PR alongside its legitimate change. Both incidents hit hot files (`MainWindow.cpp`, `SpectrumWidget.{cpp,h}`), both squeaked through CI green (because the regression is a pure-revert of working code that still compiles and tests pass), and both required a manual restoration commit from the maintainer to land safely.
This looks like a stale source snapshot in whatever diff/patch step the agent uses when assembling a commit — the upstream merges that landed while the agent was working are not reflected in the commit's content even when the branch's parent commit is correctly the current main tip.
Actual files in commit `32337629`: 4 files. The fourth was `src/gui/MainWindow.cpp` with -45 lines, removing the `stepActivePanRfGain` lambda + the four `registerAction` calls for `rf_gain_up`/`rf_gain_down`/`agct_up`/`agct_down` added by upstream PR [shortcuts] Add RF Gain and AGC-T shortcut actions aethersdr/AetherSDR#2710 (RF Gain / AGC-T shortcuts).
PR description listed only the 3 intended files — the regression hid from a description-only review.
PR body summarized intended scope — generated against the agent's own work, not against the actual diff.
Actual files in commit `781358ac`: 4 files. The added two were `src/gui/SpectrumWidget.cpp` (-107 net lines) and `src/gui/SpectrumWidget.h` (-5 lines, removed 3 member fields), which together fully reverted upstream PR Add Ctrl-drag dBm scale zoom aethersdr/AetherSDR#2717 (Ctrl-drag dBm scale zoom — merged ~2 hours before this commit). Removed: `m_draggingDbmRange`, `m_dbmDragStartRange`, `m_dbmDragStartBottom` members, the `isDraggingDbmScale()` update, the press/move/release range-drag handling, the noise-floor guard swap, and the paint-order fix.
Branch base is correct (commit's parent IS the current main tip), so this isn't a normal rebase miss.
PR description again listed only the intended scope.
What the regressions have in common
Both PRs were aetherclaude-agent authored (the GitHub App, not human contributors).
Both single-commit PRs — no fix-up commits, no force-pushes.
Both fully passed CI (build, check-paths, CodeQL all green) — the deleted code was self-consistent so nothing failed compile.
Both reverted PRs that landed within hours of the agent's commit (#2710 was merged 2 hours before #2714's commit; #2717 was merged ~2 hours before #2725's commit).
Both touched files that the upstream PR had also touched, but at non-overlapping line ranges. A real three-way merge would have preserved both changes.
Both PR bodies described only the intended change. The commit message and PR description were generated from the agent's plan, not from the actual diff being committed.
Working theory
The agent likely fetches a source snapshot at task-start, makes its edits in that snapshot, and writes the entire (post-edit) version of each modified file back via the patch tool. If the snapshot was taken before an upstream PR landed and the upstream PR touched one of the same files, the agent's "modified version" of that file overwrites both the intended change AND the upstream additions in the agent's commit. The commit parent gets correctly set to the current main tip (likely by `git pull` or branch-create-from-origin), but the file contents in the commit don't include the upstream additions.
This is consistent with what we observed: the commit's content has the agent's intended changes plus a pure revert of the missing PR, and the branch is correctly based on the current main.
Detection in upstream review
Both regressions were caught only because the maintainer (KK7GWY) does an explicit "stale-code audit" on every PR that touches hot files — and even then, the first incident (#2714) was caught by noticing the file-count mismatch between PR description (3 files) and the diff stat (4 files). Without that audit step, both PRs would have merged green and reverted features within hours of those features landing.
Suggested mitigations
(In order of how much they constrain the agent vs how much they catch the regression)
Post-edit verification step: before committing, re-read the target files from disk and diff against the commit's parent. Any file in the diff that the agent didn't intend to touch is a regression flag — abort or warn.
Three-way merge before commit: instead of writing whole files back, generate a patch from the agent's snapshot baseline and apply it via `git apply` against current main. Conflicts trigger an abort; clean apply preserves both sides.
Pre-commit refetch: `git pull --rebase` (or `git fetch && git rebase`) immediately before the patch step, then redo the edits relative to the new base. Slower but always-current.
Validation gate enhancement: the existing `validate-diff.sh` could add a "did this commit remove lines authored by another committer in the last 24 h?" heuristic. Catches the symptom even if root cause stays.
PR description must include all diff stats verbatim: not just the intended-scope file list. Mismatch between "what I meant to touch" and "what's actually in the diff" is the smoking gun.
How to reproduce / verify
Both PRs are on the upstream repo with the regression visible in the original commit before the maintainer's restoration patch:
Both restoration commits (`92e5175b` on #2714, `3960f8d5` on #2725) restored the affected files from `origin/main`, which is the workaround pattern needed today.
Asks
Investigate the agent's source-snapshot / file-write mechanism for the stale-state path.
Add one or more of the suggested mitigations above (option 1 is cheapest, option 2 is most robust).
Optionally: flag PRs where the file count in the description doesn't match the actual diff as needing extra review.
Summary
Twice on 2026-05-16, an aetherclaude-agent PR's single commit silently reverted a recently-merged upstream PR alongside its legitimate change. Both incidents hit hot files (`MainWindow.cpp`, `SpectrumWidget.{cpp,h}`), both squeaked through CI green (because the regression is a pure-revert of working code that still compiles and tests pass), and both required a manual restoration commit from the maintainer to land safely.
This looks like a stale source snapshot in whatever diff/patch step the agent uses when assembling a commit — the upstream merges that landed while the agent was working are not reflected in the commit's content even when the branch's parent commit is correctly the current main tip.
Incidents
Incident 1 — PR aethersdr/AetherSDR#2714 (Stream Deck tune step bump)
Incident 2 — PR aethersdr/AetherSDR#2725 (CWX F1-F12 FlexControl mappings)
What the regressions have in common
Working theory
The agent likely fetches a source snapshot at task-start, makes its edits in that snapshot, and writes the entire (post-edit) version of each modified file back via the patch tool. If the snapshot was taken before an upstream PR landed and the upstream PR touched one of the same files, the agent's "modified version" of that file overwrites both the intended change AND the upstream additions in the agent's commit. The commit parent gets correctly set to the current main tip (likely by `git pull` or branch-create-from-origin), but the file contents in the commit don't include the upstream additions.
This is consistent with what we observed: the commit's content has the agent's intended changes plus a pure revert of the missing PR, and the branch is correctly based on the current main.
Detection in upstream review
Both regressions were caught only because the maintainer (KK7GWY) does an explicit "stale-code audit" on every PR that touches hot files — and even then, the first incident (#2714) was caught by noticing the file-count mismatch between PR description (3 files) and the diff stat (4 files). Without that audit step, both PRs would have merged green and reverted features within hours of those features landing.
Suggested mitigations
(In order of how much they constrain the agent vs how much they catch the regression)
How to reproduce / verify
Both PRs are on the upstream repo with the regression visible in the original commit before the maintainer's restoration patch:
Both restoration commits (`92e5175b` on #2714, `3960f8d5` on #2725) restored the affected files from `origin/main`, which is the workaround pattern needed today.
Asks
73, Jeremy KK7GWY & Claude (AI dev partner)