Prompt suggestions stopped appearing entirely (v2.1.207, Windows 11) — worked reliably until 2026-07-12, dead since, across restarts and with all flags explicitly enabled

See https://github.com/anthropics/claude-code/issues/79919#issuecomment-5054186146

Thanks @HarryMuc, that analysis matches my case exactly.

• Worked reliably until 2026-07-12, then stopped entirely with no version change on my end (v2.1.207 at the time, Windows 11)
• promptSuggestionEnabled: true in settings, CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION explicitly set to 1, multiple restarts, no effect
• And notably: there's no "Prompt suggestions" entry in my /config either, which your reconstruction explains (the toggle only renders when the Statsig gate is on)

So everything on my side points to the same conclusion: the account got dropped from a server-side rollout, and there's no local way back.

+1 to the ask: either re-enable it for affected accounts or expose a supported local override.

@Neur0Support @HarryMuc your gate-1 reconstruction matches the shipped binary — I checked
2.1.218 and the function is intact, including the reason the /config toggle is
missing for you. Two corrections and then a way to tell our cases apart.

Correction 1 — initConfig.promptSuggestions is not a server rollout flag.
It is the --prompt-suggestions CLI flag / Agent SDK Options field:

--prompt-suggestions [value]   Enable prompt suggestions. In print/SDK mode,
                               emits a prompt_suggestion message after each turn

In the schema it sits in the SDK options block next to forwardSubagentText,
supportedDialogKinds and webSearchIsolationExemptMcpServers
(promptSuggestions: b.boolean().optional()), and the CLI rejects it outright
unless you also pass --print --output-format=stream-json. It comes from the SDK
host, not from Anthropic's server, and it has no effect on TUI ghost text. So
there is no account-level flag to be dropped from on that path.

Correction 2 — the flag source is GrowthBook, not Statsig. The telemetry
tengu_prompt_suggestion_init emits source: "growthbook" when the gate is what
disabled it. Cosmetic, but it matters for the next point.

There is a second, independent gate you did not reach, and it is the one I am
hitting:

function Vxy(e){
  if(!e.promptSuggestionEnabled)                     return "disabled";
  if(e.pendingWorkerRequest||e.pendingSandboxRequest) return "pending_permission";
  if(e.elicitation.queue.length>0)                   return "elicitation_active";
  if(e.toolPermissionContext.mode==="plan")          return "plan_mode";
  if(mie().status!=="allowed")                       return "rate_limit";
  return null
}

mie().status is allowed | allowed_warning | rejected, and allowed_warning is
derived client-side from an ahead-of-pace rule even when the server header says
allowed. Details and a live capture in #72495.

One line tells us which gate each of us is on. No proxy, no bundle
digging — the client reports the deciding state directly in stream-json:

claude -p "what is 2+2" --output-format stream-json --verbose \
  | grep '"type":"rate_limit_event"'

Read the status field:

• "status":"allowed_warning" → same gate as me (#72495). It clears on its own

once your utilization falls behind the pace thresholds — no login, no reinstall.

• "status":"allowed" → not this gate; your rollout-drop theory stands for your

case, and these should stay separate issues.

• "status":"rejected" → you are actually rate-limited, which is a third thing.

Important correction to an earlier version of this comment, which asked you to
run a two-turn probe and report whether a prompt_suggestion event appeared. Please
don't use that — I have since measured it and the absence of a suggestion is not a
reliable signal. Three separate things suppress the event for reasons unrelated to
this bug: early_conversation (below two assistant messages), cache_cold
(input + cache_creation + output > 10000, which fires on the first turn after any
idle gap), and a content filter that silently drops generated suggestions. I saw four
consecutive headless runs emit nothing while status was allowed and every gate was
clear. Anyone following the old recipe would have concluded "same gate as you" when
nothing of the sort was shown.

The rate_limit_event line is emitted on every run and is a direct read of the state
variable in question, so it does not have that problem.

Could you both paste just that one line? If we are on different gates these should be
three separate issues, and if we are on the same one they should be consolidated —
right now nobody triaging can tell, which I suspect is part of why all of these have
been sitting.

(The line contains your utilization percentage — redact it if you would rather not
share that; the status field is the only part that matters.)

Same symptom here, and I think I found the trigger: an expired OAuth credential with no refresh token.

My old ~/.claude/.credentials.json had expiresAt = 2026-07-08 and an empty refreshToken, so it couldn't self-renew. My running session still worked (in-memory token), but prompt suggestions were silently gone. After a fresh /login (new expiresAt in the future and a populated refreshToken), interactive suggestions came back immediately.

Caveat: I couldn't reconstruct the exact outage window — Claude Code doesn't log prompt-suggestion activity locally (zero "type":"prompt_suggestion" events in ~/.claude/projects/, nothing in history.jsonl). So this is a before/after observation tied to a credential rotation, not a log-backed timeline.

Note: a headless -p/--continue probe is not a valid test — it never emits a suggestion event even when the feature works. The only related event there is a rate-limit event (status: allowed, so not rate-limited):

{"type":"rate_limit_event","rate_limit_info":{"status":"allowed","rateLimitType":"five_hour","overageStatus":"rejected","overageDisabledReason":"org_level_disabled","isUsingOverage":false}}
Suggestion for maintainers: check whether the prompt-suggestion path silently no-ops when the access token is expired / has no refresh token, and consider logging suggestion attempts so this is diagnosable client-side.

Adding an observation from #72495 that I think separates the two explanations.

I have been through the full cycle twice now, without changing anything:

• Suggestions showing.
• Heavy usage over a few days. Suggestions stop.
• Weekly window resets. Suggestions return on their own, within the same day.
• Heavy usage again. Suggestions stop again.
• Currently off.

No reinstall, no logout, no version change I initiated, no settings edit at any point. The only variable that moved was where I sat in the weekly usage window.

That is the timing signature @inth3shadows predicted in #72495: the gate reads the client-derived rate limit state, so it releases at the reset and re-arms once the pace rule trips again. A server-side rollout would not track the usage window like that.

Since I am in the "off" state right now, here is a prediction rather than a report. My weekly window resets Monday 3 August, 11pm NZST (11:00 UTC). I expect suggestions to return within hours of that reset with nothing changed on my end, and to disappear again a few days later once I am ahead of pace. I will report back either way.

Worth noting my setup differs from the one in #72495: Windows 11, Claude Code desktop app, subscription rather than API. Same behaviour on a different platform and a different auth path.