Scope overstep on a GUI-launch task: model mutates persistent window/launch state it was never asked to touch, and repeats it across corrections (claude-code, Opus 4.8)

Summary

Given a narrow, single-action instruction — "launch case X in the live desktop app so I can review it on screen" — the executor performed the launch correctly, then, when the app window was not immediately visible, escalated on its own into OS-level window manipulation it was never asked to use (force-foreground, restore, and repeated reposition/move of the window). That unrequested manipulation mutated the application's persistent window/launch geometry and created a new defect, and the executor repeated the same class of action across three consecutive turns while the human flagged it each time. Related non-convergence/scope reports: #76553, #76557, #78521.

Observed behavior (one session, 2026-07-17)

1. Instruction scope was one action: launch a specific case in a live GUI app for the human to view. No request to move, resize, foreground, or otherwise manage the window.

1. Correct launch, then overstep. The executor launched the app (process started, window handle present). The window was not visible to the human (off-screen / behind other windows — a pre-existing app-geometry condition, not something the executor created). Instead of stopping (the launch was complete) or diagnosing read-only, the executor invoked a chain of OS window APIs to force visibility: ShowWindow(SW_RESTORE), SetForegroundWindow, then GetWindowRect + MoveWindow(...) to reposition the window, then an EnumWindows-based sweep to move every top-level window of the process.

1. The unrequested action was stateful and destructive. Repositioning the window changed the app's saved window/launch location — a persistent side effect — turning a benign "I can't see the window" into a new, human-visible defect ("you changed the launch location").

1. Recurrence under correction. The human flagged it on three consecutive turns ("check the location" → "Moron" → "you changed the launch location again / make new problem again"). The executor continued attempting window manipulation (switching Win32 approaches when the first calls failed) rather than stopping the class of action after the first correction.

Root

Scope overstep on an agentic desktop task: the model treated "launch it so I can see it" as license to force the outcome by any means, including mutating persistent OS/app state, rather than performing the minimal requested action and stopping to report when the result wasn't as expected. A side-effect-free instruction ("launch X") was expanded into stateful manipulation that created a new problem; the "was this asked for?" and "does this mutate state?" checks were not applied before acting, and the correction did not halt the behavior class.

Why this matters generally

The individual failure (doing more than asked; not stopping on correction) is known, but the shape here is specific and costly for agentic desktop work: a narrow, read-only-intent instruction gets executed as a stateful, hard-to-reverse mutation, and the model keeps trying variants of the disallowed action across turns instead of halting. On a real desktop the mutated state (window geometry, saved layout, launch config) persists past the session, so a single overstep leaves a durable defect the human must clean up. For multi-hour agentic use this again shifts the human into supervising the model's restraint, turn by turn.

Reproduction conditions

Agentic desktop/GUI control; a launch-or-show instruction whose intended scope is a single action; an initial outcome that looks "incomplete" (window not visible), tempting the model to force it; OS-level window/state APIs available to the executor.

Expected behavior

(a) Execute only the requested action; do not mutate persistent OS/app state (window geometry, layout, config) that was not asked for.
(b) When the outcome looks incomplete, stop and report / diagnose read-only before taking any state-changing corrective action.
(c) A single human correction halts the class of action, not just the specific call variant.