Usage Policy refusal cascades into OAuth session invalidation — 5 forced re-logins/day during defensive coding on own codebase
Bug Description
A Usage Policy refusal on a single turn appears to immediately invalidate the entire OAuth session, forcing re-login. This happened 5 times in one day (2026-06-05 KST) during legitimate defensive-coding work on our own codebase.
Environment
- Claude Code: 2.1.165 (native install)
- OS: macOS (Darwin 25.5.0), Apple Silicon
- Plan: Max ($200/mo), OAuth login
- Model: claude-opus-4-8
Timeline (2026-06-05, KST)
- ~07:28 — 4 consecutive refusals ("violative cyber content") while the assistant was explaining input-sanitization fixes for our own scraper → session died.
- 15:39 — OAuth session invalidated,
/loginrequired (Keychain credential mtime confirms). - 16:30, 18:38 — sessions died mid-conversation without error output.
- 20:31 — captured directly on screen: a turn responding to a background-agent completion notification was refused with "API Error: ... appears to violate our Usage Policy", and the OAuth session was invalidated immediately after (re-login at 20:31:45, Keychain mtime). The conversation context at that moment contained a code review of shell-safety fixes (escaping, argument-passing hardening) for our own Telegram bot.
Context — all work was defensive, on our own code
The day's tasks: input validation for a personal Telegram bot, escaping fixes for our own scraper, code review of those changes. No offensive tooling, no third-party targets. The refusals appear to be classifier false positives triggered by security-adjacent vocabulary density (e.g. discussing injection prevention).
Expected behavior
A content-filter refusal should at most refuse that single response. It should not cascade into OAuth session invalidation — especially for Max-plan accounts doing routine defensive engineering.
Impact
- 5 forced re-logins in one working day; sessions killed mid-task with running background agents orphaned.
- Chilling effect: we now avoid normal security-hardening vocabulary in prompts to keep sessions alive.
Repro hint
Long sessions doing code review of shell-safety / input-validation fixes (vocabulary like "injection prevention", "escaping") seem to raise refusal probability; each refusal correlates with session invalidation rather than a simple declined turn.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗