{"version":"2.1.235","anchor":"account-on-hold-handling-is-built-end-to-end-but-dark-behind","canonical_anchor":"account-on-hold-handling-is-built-end-to-end-but-dark-behind","heading":"Account-on-hold handling is built end-to-end but dark behind tengu_lively_beaver (fallback: off)","tier":"soon","area":"Auth","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.235\/e\/account-on-hold-handling-is-built-end-to-end-but-dark-behind","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.235","markdown":"### Account-on-hold handling is built end-to-end but dark behind `tengu_lively_beaver` (fallback: off)\n\nA full account-on-hold sign-in flow was added but stays unreachable pending a server-side gate\n\nClaude Code now has a dedicated path for accounts placed on hold: a new `OAuthAccountOnHoldError`\/`OAuthCallbackError` pair, an `account_on_hold` login-screen state, a `cli_setup_token` branch, an `api_request_account_on_hold` error branch, a `tengu_oauth_refresh_token_account_on_hold` refresh outcome, and an `account_on_hold` value added to the `StopFailure` hook matcher list. The local OAuth callback listener now handles `?error=` redirects (previously only `code` was handled), and an appeal link is validated to be https-only, pointing at claude.ai or anthropic.com or a subdomain, else it falls back to a fixed restricted-access URL.\n\nEvery entry point funnels through one detector gated on `tengu_lively_beaver`, which falls back to off. Nothing in the build sets this gate true, and the hook metadata doesn't even advertise `account_on_hold` unless it is.\n\n- Flag `tengu_lively_beaver`: Off in both readings (read for one account on one subscription tier against v2.1.235; this account: off, anonymous baseline: off, compiled default: not a boolean we can read)\n- Area: Auth\n- Tier: Nothing to try yet\n- Useful: 5\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}