Prompt suggestions (grey ghost-text, Tab to accept) never appear in GUI app despite promptSuggestionEnabled: true

Prompt suggestions (ghost text) no longer appear after update — appears to be a server-side rollout gate

Environment

• Claude Code (native install), Windows 11
• Version: 2.1.217 (regression first noticed after updating; also reproduced on a clean 2.1.217)
• Not in plan mode (Auto mode), fresh session, checked after the first assistant response

Symptom
The grey inline "prompt suggestions" (accept via Tab/→) used to appear regularly and stopped appearing entirely. They no longer show under any condition.

What I ruled out locally

• ~/.claude/settings.json has "promptSuggestionEnabled": true
• No CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION disabling it; I also explicitly set it to 1 (User env), restarted — no effect
• There is no "Prompt suggestions" entry in /config to toggle
• Updated to latest (2.1.217), restarted — no effect

Root cause (reconstructed from the 2.1.217 bundle)
There appear to be two independent gates; the local controls only cover one of them.

1. Client-side enablement — promptSuggestionEnabled: vTo():

• vTo(): env CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION = 1/true/yes/on → force ON; 0/false/no/off → force OFF; otherwise requires Statsig gate tengu_chomp_inflection to be ON, else falls back to the promptSuggestionEnabled setting.
• The /config toggle is only rendered when tengu_chomp_inflection is ON: Ke("tengu_chomp_inflection", false) ? [{ id:"promptSuggestionEnabled", label:"Prompt suggestions", … }] : [] — which is why the toggle is absent for me.

1. Runtime query gate — a separate field:

• Condition: d.promptSuggestions && kr.shouldQuery !== false && !dE() && !ku(process.env.CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION)
• d.promptSuggestions is populated from this.initConfig?.promptSuggestions (session init config; schema promptSuggestions: boolean().optional()), i.e. delivered by the server per account.

The env var / setting only drive promptSuggestionEnabled (client half). The actual ghost-text query additionally requires d.promptSuggestions, which comes from the server-provided initConfig and has no local override. If the server does not send promptSuggestions: true for the account, the query never fires — regardless of local settings, the env var, or the version.

Conclusion
This looks like a server-side rollout/experiment (tengu_chomp_inflection + initConfig.promptSuggestions) from which my account was dropped, not a local misconfiguration. There is no client-side way to force it back on.

Ask

• Is that intended? Can prompt suggestions be re-enabled for this account?
• If the two-gate design is intended, please expose a supported way to enable it locally, and add the CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION variable + the promptSuggestionEnabled setting to the official settings/env-var reference (currently only mentioned in interactive-mode.md).

@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.)

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.

Data point that may reframe this: the GUI app does support prompt suggestions — they work there. I had ghost text in the desktop app throughout the morning of 2026-07-31 and it stopped mid-afternoon the same day. So this isn't "unsupported in GUI," it's a regression.

Version 2.1.219, desktop app 1.24012.9, macOS Darwin 25.5.0.

Nothing changed locally across the break:

• App bundle unmodified since 07-24; no CLI update landed today.
• tengu_prompt_suggestion: true in ~/.claude.json → cachedGrowthBookFeatures, cache refreshed the same afternoon.
• Setting promptSuggestionEnabled: true explicitly in ~/.claude/settings.json made no difference.
• Full app restart made no difference.
• Not context length — reproduces on a brand-new session.
• Suggestions are never written to the session transcript, so there's no local artifact to diff a working session against a broken one.

Since the machine was unchanged either side of the break, this looks server-side rather than a client bug.

Same here, and still present on a newer version.

Environment: Claude Code 2.1.222, desktop app (CLAUDE_CODE_ENTRYPOINT=claude-desktop), macOS 26.6.1 (build 25G76), Apple M1 Max. Reproduced after a full OS update and a restart of both the machine and the app.

Beyond the checks in the original report, I also ruled out:

CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION is not set anywhere — not in the process environment, not in .zshrc / .zprofile / .zshenv / .bash_profile / .bashrc / .profile, and not in launchctl getenv
All four documented skip conditions: not the first turn of the conversation, not plan mode, not print mode, and not a cold prompt cache — suggestions are equally absent on rapid consecutive turns in an active session
Effort level is max, so nothing is being throttled for cost
Replies deliberately ended in a single concrete next step, since the suggestion is generated from how the reply ends
Two observations that may help diagnose it:

Suggestions leave no trace in the session transcript. I searched every ~/.claude/projects/**/*.jsonl on the machine and found no record of a generated suggestion. That makes it impossible for a user to distinguish "no suggestion was generated" from "one was generated but never rendered" — which is probably why this is awkward to report precisely. A log line on generation would make the failure mode observable.

The documented toggle location does not exist on this surface. The Interactive mode page says to toggle the setting in /config, but /config opens an interactive terminal panel that is not available in the desktop app. That is at least consistent with parts of that page applying to the terminal client only.

Seconding the original question, since it is the one that would settle this: is the prompt suggestion feature supported in the GUI app, or is it specific to the terminal CLI? If it is terminal-only, saying so on the Interactive mode page would resolve it for everyone who goes looking.

Update: resolved for me — with no client-side change, which may be the useful data point.

Prompt suggestions started appearing today (2026-08-08) and work exactly as documented: grey ghost-text after a reply, Tab/Right arrow to accept, Enter to submit.

What did NOT change between my last failing test and the first success:

Claude Code version: 2.1.222 both before and after (verified against the installed app bundle and the running process — no app update in between)
Same machine, same desktop app, same settings (promptSuggestionEnabled: true was already set during the failing tests)
A full macOS update (26.6.1) + restart of machine and app had already been tried the day before, and suggestions were still absent after that — so the restart was not the fix either
What did change:

Roughly 24 hours passed
I switched the session model (previously Opus, now a different model) — though the failing tests had been consistent across many sessions before that, so I doubt this is it
Given identical client version and config on both sides of the fix, this looks consistent with a server-side rollout or flag flip rather than anything local. If that matches something on your end, it might explain the reports on this issue — and confirms the feature does work in the desktop app.

Thanks — happy to test anything if it regresses.