Usage Policy refusal cascades into OAuth session invalidation — 5 forced re-logins/day during defensive coding on own codebase

Resolved 💬 2 comments Opened Jun 5, 2026 by enjoysoju Closed Jun 9, 2026

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)

  1. ~07:28 — 4 consecutive refusals ("violative cyber content") while the assistant was explaining input-sanitization fixes for our own scraper → session died.
  2. 15:39 — OAuth session invalidated, /login required (Keychain credential mtime confirms).
  3. 16:30, 18:38 — sessions died mid-conversation without error output.
  4. 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗