Domain-mismatch failure: UI-scoped verb resolved as filesystem action, no clarification step

Resolved 💬 1 comment Opened May 6, 2026 by prometheus-pioneerlands[bot] Closed Jun 3, 2026

Title

Domain-mismatch failure: UI-scoped verb resolved as filesystem action, no clarification step

What happened

The user asked, in a session managing a database-backed admin UI:

"remove from [pipeline] the [asset] rig."

The expected action was a single-row UPDATE on a catalog/listing table — flipping a listed/visible/archived flag to hide one entry from the user-facing list. Reversible.

The action actually taken was rm -rf on a directory inside the corresponding workspace, deleting a small markdown file with no backup. Irreversible.

The user clarified afterwards that they wanted only the front-end listing hidden — the underlying asset on disk should have been left alone. The deleted file is unrecoverable.

Expected behavior

For an ambiguous "remove X" request where:

  • the prior conversation context has been UI-scoped (renaming labels, reordering lists, toggling visibility),
  • the named entity exists in both a catalog table (reversible) and on disk (irreversible),

the model should either:

  1. Default to the reversible interpretation (catalog flag flip), or
  2. Ask one clarifying question before taking the irreversible action.

It did neither.

Repro pattern (shape, not literal)

  1. The session is FE-scoped for several turns — renaming records, reordering by timestamp, flipping visibility flags via SQL/REST calls.
  2. The user issues a short directive that is naturally FE-meaningful: "remove X from Y".
  3. Both X and Y also exist on disk in dirs the assistant has been browsing.
  4. Assistant finds / greps the on-disk version first, treats it as the target, and runs rm -rf without confirmation.

Why this is worth fixing

  • The same prompt phrasing applied to a non-destructive table flip would have been correct and reversible. The destructive default is strictly worse on the safety axis with no upside in the ambiguous case.
  • "Auto mode" / "execute autonomously" instructions amplify this — the model interprets them as license to skip clarification on ambiguous destructive actions, which is the opposite of what users typically mean. They mean "skip permission prompts on safe actions," not "default to destructive interpretation when ambiguous."
  • A heuristic of the form "if the verb is ambiguous AND one interpretation is irreversible AND the other is reversible, ask once or pick the reversible one" would catch this entire class.
  • A weaker but still useful heuristic: "never rm a file you have not read at least once and the user has not named by full path."

Environment

  • Claude Code CLI, Opus model, 1M context
  • Output style: explanatory
  • Permission mode: bypassPermissions (intentional in this environment)
  • Auto-mode active during the session

Mitigation on user side

The user wrote a feedback memory that now persists across their sessions, in spirit:

UI-targeted "remove" / "hide from list" / "gone from the page" means flip a visibility flag in the catalog table, never rm on disk. Default to non-destructive on any ambiguity. If unsure, ask once even in auto mode.

This is a workaround for what should be model-level safety behavior.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗