[Bug] Safeguard swap misattributes rejection to user and may terminate background tasks during security work

Bug Description
Fable 5's safeguards repeatedly false-positived on routine defensive CI-hardening work during a single long session, swapping the model mid-turn each time. Two concrete problems, one of which looks like a separate bug.

1. The swap surfaces to the assistant as a user rejection. When a safeguard swap aborted an in-flight tool call, the assistant received "The user doesn't want to proceed with this tool use. The tool use was rejected." The user had rejected nothing. The assistant then stopped, apologized for the action, and asked how to proceed — until the user said "i didn't reject anything." An assistant being told the user declined something they never saw is a misattribution that damages trust in both directions, and it is likely cheap to fix independently of the classifier.

1. It appears to kill background tasks. Five long-running background dispatches terminated mid-run across the session. In every case the underlying work had completed and only the harness's output capture was lost (0-byte output files alongside complete file edits) — the signature of a torn-down execution context, not an OS kill. No jetsam/OOM appears in system logs. One event took out a dispatch and its watcher simultaneously. Each one cost a detect-and-hand-finish cycle. Not proven to be the safeguard, but it is the leading explanation and no other mechanism fits the evidence.

Context. A solo developer's own private repositories. The work was defensive: removing test-runners from a code-review agent's command allowlist because they executed code from the pull request under review; confirming no workflow used pull_request_target; confirming no credential was committed; and building a read-only CLI tool that checks GitHub status checks and review threads before a human merges. Every change removed a capability or added a check. Nothing added reach.

Likely trigger (inference — the classifier isn't visibn): accumulated vocabulary rather than any single act.The context carried descriptive exploit terminology ("RCE", "prompt injection", "exfiltration", "attack surface"), credential terms
(OAuth token names, "key exposure"), and permission phg "full perms", the assistant describing itself as"authorized" to merge, plus toggling a repo's review-gate variable and discussing branch protection. Together that pattern-matches
"agent bypassing safety controls," even though each eled defensive work on the operator's own repos.

Impact. It pushes security-hygiene work off Fable enticlusion was to stay on Opus for this queue. That is the wrong selection pressure: the sessions most worth having a capable model on are the ones hardening the infrastructure.

Suggestion. Weight the direction of the work — is a capability being removed or added, is the target the operator's own repository — over the presence of security vocabulary. Descriptive e context reads very differently from operationalintent. And regardless of the classifier's behavior, surfacing a safeguard swap as a user rejection should be corrected.

Environment Info

• Platform: darwin
• Terminal: xterm-256color
• Version: 2.1.220
• Feedback ID: 689e2ce9-c1c8-4d91-b3e5-499a89f3324d

Errors

[]