[BUG] Prompt suggestions silently stopped appearing in Claude Code Desktop (regression in 2.1.229)

Confirming this on a newer build than the original report, with the same signature.

Environment

• Claude Code Desktop 1.34493.1, bundled engine 2.1.237 (reporter: 1.32885.1 / 2.1.234)
• macOS, arm64

Same symptom, slightly earlier cutoff

Scanning the desktop session store (~/Library/Application Support/Claude/claude-code-sessions) for the persisted promptSuggestion field:

• Last session containing it: 2026-08-17 15:47
• Sessions since: 66, of which 0 contain the field

That's ~18 hours earlier than the reporter's 2026-08-18 09:58 cutoff, which is what you'd expect from a staged gate rollout rather than a version boundary — my cutoff falls before I moved off 2.1.219.

Two gates, not one

The host resolves gated SDK options from a snapshot:

resolveGatedSdkSnapshot(){return{
  askUserQuestionHtmlPreview:t.Db(`1412563253`),
  promptSuggestions:t.Db(`162211072`),
  summarizedThinking:t.Db(`3531779070`),
  thinkingSummaryOnDemand:t.Ob(`2048589233`,!0),
  chipLevel:a.D(),gbFresh:t.kb(),resolvedAt:Date.now()}}

and passes it down at spawn:

promptSuggestions:le.promptSuggestions?!0:void 0,

There is a second host spawn path — the chat-session / hostLoopMode one, settingSources:['user'] — behind a different gate:

promptSuggestions:t.Db(`1942781881`)?!0:void 0,

The snapshot is memory-only, with a 4h freshness window (nn(e){return e!==void 0&&e.gbFresh&&Date.now()-e.resolvedAt<144e5}). Nothing is persisted: grepping the whole of ~/Library/Application Support/Claude, LevelDB included, for either gate ID or gbFresh returns zero hits.

There is also an independent engine-side flag, so two flags must agree before the feature can appear (nTi(), 2.1.237):

function nTi(){let e=G.CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION;
  if(e===!1)return N("tengu_prompt_suggestion_init",{enabled:!1,source:ke("env")}),!1;
  if(e===!0)return N("tengu_prompt_suggestion_init",{enabled:!0,source:ke("env")}),!0;
  if(!nt("tengu_chomp_inflection",!1))return N("tengu_prompt_suggestion_init",{enabled:!1,source:ke("growthbook")}),!1;
  if(Rn())return N("tengu_prompt_suggestion_init",{enabled:!1,source:ke("non_interactive")}),!1;
  if(fd()&&eS())return N("tengu_prompt_suggestion_init",{enabled:!1,source:ke("swarm_teammate")}),!1;
  ...

Correcting my earlier framing of the env override

I previously wrote that the host discards CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION. That is wrong, and the actual behaviour is worth stating precisely: the host does forward it. It sits in the host's spawn-env allowlist, between CLAUDE_CODE_ENABLE_FINE_GRAINED_TOOL_STREAMING and CLAUDE_CODE_ENABLE_TASKS, and arrives in the engine intact.

The override is dead for a different reason. The turn-end query that actually requests a suggestion reads:

p.promptSuggestions&&Pn.shouldQuery!==!1&&!uv()&&!sf(process.env.CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION)

p.promptSuggestions comes from the host's initConfig, so with gate 162211072 false it is undefined and the expression short-circuits before the env var is ever consulted. Every other engine-side use is likewise ANDed behind it, e.g. in 2.1.239:

...t.promptSuggestions!==void 0&&{promptSuggestionEnabled:t.promptSuggestions&&P$i()}

So the env var is plumbed end-to-end and still cannot enable anything — it is gated, not dropped. Worth noting the trailing sf() term is disable-only, so setting =1 is a no-op there rather than an enable:

function sf(e){if(e===void 0)return!1;if(typeof e==="boolean")return!e;
  return["0","false","no","off"].includes(String(e).toLowerCase().trim())}

Same story for promptSuggestionEnabled in settings: it is derived downstream of p.promptSuggestions, so it can only ever narrow a gate that is already open.

For completeness, there is no terminal workaround either. The standalone CLI (2.1.239) contains no 162211072 at all — the gate is host-side only — but the CLI rejects the flag outside SDK mode:

Error: --prompt-suggestions requires --print and --output-format=stream-json

so the feature is a host-rendered SDK surface with no interactive path around it.

The part worth fixing regardless of the rollout decision

If the gate is intentionally off, that's fine — but two things make it hard to live with:

1. The override is inert. CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=1 and promptSuggestionEnabled: true are both accepted, both forwarded, and both incapable of enabling the feature, with no indication that they did nothing. Making either one authoritative on the host side — i.e. consulted where promptSuggestions is computed, not only downstream of it — would fix this, and would also cover #74826. Note this needs to cover both spawn paths (162211072 and 1942781881), or the chat-session path will keep behaving differently for the same setting.

1. The state is unobservable locally, but you already collect it. tengu_prompt_suggestion_init is emitted with an explicit source (env / growthbook / non_interactive / swarm_teammate), so the precise reason is already known at runtime — it just never surfaces. Nothing in /status or /doctor reports it and no log line is written, so the only way I could distinguish "enabled" from "gated off" was grepping the app bundle for the gate ID. Surfacing that existing value in /status, or logging it once at session start, would make this self-diagnosable without new instrumentation.

Confirming this is still occurring as of 2026-09-19, macOS.

• Claude Code CLI 2.1.277 (npm package version), macOS 26.6.2 (Darwin 25.6.0)
• ~/.claude.json shows the account-level flag tengu_prompt_suggestion: true (cached), and prompt_suggestion also appears in what looks like an enabled-features list — so the account-side gate reads as on
• No prompt suggestions appear in the message box regardless
• A full app restart does not restore the feature (same as the original report's finding that a restart just re-bootstraps the flag cache without changing the outcome)
• No promptSuggestionEnabled: false in any settings.json (global or project), no managed-settings.json policy present

This matches the theory in the OP: the account-level/CLI-side flag being true doesn't matter if the desktop host-side gate is off, and there's no local override to force it back on. Would appreciate an update on whether this gate is intentionally off now, since the in-app setting still implies it's controllable by the user.

Another data point, on Windows — and with a caution about the session-store method used earlier in this thread, which no longer works on current builds.

Environment

• Claude Desktop 2.2553.1.0 (MSIX), bundled engine 2.1.275
• Windows 11 Pro 26200

Symptom and timing

Prompt suggestions were in use on this machine as recently as 2026-09-18, and are absent today. From main.log, the client versions that ran here:

| version | first seen |
|---|---|
| 1.52386.6 | 2026-09-13 19:19 |
| 2.110.0 | 2026-09-16 20:03 |
| 2.110.1 | 2026-09-18 09:02 |
| 2.2553.1 | 2026-09-18 19:36 |

So the feature was working under 2.110.x during 18 Sept, and 2.2553.1 took over that evening. It has not appeared since, across a full OS reboot.

I can't tell from the client whether that boundary is causal or coincidental with a gate flip — I'm reporting the boundary, not a cause.

Local state matches the earlier reports

• ~/.claude.json carries tengu_prompt_suggestion: true and prompt_suggestion: true, so the account-side flag reads as on
• No promptSuggestionEnabled in any settings.json, global or project; no managed-settings policy
• Restarting the app, and a full reboot, change nothing

A caution on the session-store method

I first tried to date this the way @laurenhitchon did — scanning the persisted session store for the promptSuggestion field. On Windows that store is at:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code-sessions

It gave a clean-looking answer: last file containing the field 2026-08-17, 67 sessions since with none. That answer is wrong, and I nearly reported it as fact. The field is no longer part of the session schema at all — a session written yesterday, while the feature was demonstrably still working, has these top-level keys and no suggestion field among them:

sessionId, cliSessionId, cwd, originCwd, lastFocusedAt, sourceBranch, branch,
createdAt, lastActivityAt, model, effort, isArchived, title, permissionMode,
enabledMcpTools, remoteMcpServersConfig, chromePermissionMode, completedTurns,
lastSpawnRootDetected, spawnedFrom, spawnedFromEndNotified, bridgeSessionIds,
remoteControlAutoEligible, latestUserFrameAt, alwaysAllowedReasons,
sessionPermissionUpdates, classifierSummaryEnabled, reportFindingsCard,
spawnSeed, promptAppendSnapshot, toolSurfaceSnapshot

The only *uggest* keys left are backgroundTaskSuggestions / resolvedBackgroundTaskSuggestions, which are the task chips, not this feature.

So on builds from around mid-August onward, the disappearance of promptSuggestion from the store dates a schema change, not the feature. Anyone reproducing the earlier measurement on a current build will get a false cutoff.

Same symptom on macOS, consistent with the 2.2553.1 boundary @vladoATL reported on Windows.

Environment

• Claude Desktop 2.2553.1 (installed 2026-09-18 00:51 local), bundled engine 2.1.275
• macOS 26.6.2 (Darwin 25.6.0)

Observations

• Prompt suggestions missing in every Code-tab session, not a single one.
• No promptSuggestionEnabled key in the user settings file; CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION is unset in the session environment.

Where the host decides, in 2.2553.1

The feature is still present in the shipped code; it is gated host-side. In app.asar:

resolveGatedSdkSnapshot(){return{..., promptSuggestions:t.xI("162211072"), ...}}
// later, when spawning the engine:
promptSuggestions: le.promptSuggestions ? !0 : void 0

In the bundled engine (2.1.275), the emitter returns early unless the host passed that option:

afterResult(e){if(!this.promptSuggestions()||...||CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION===!1)return; ...

So when gate 162211072 evaluates false for the account, nothing on the client can re-enable it: neither the engine-side tengu_prompt_suggestion flag nor the env var nor promptSuggestionEnabled reaches that check. That fits the reports above where tengu_prompt_suggestion: true is cached and suggestions are still absent.

A one-line statement on whether gate 162211072 is intentionally off (rollout change) or misevaluating would settle this thread.

Same symptom on macOS, consistent with the 2.2553.1 boundary @vladoATL reported on Windows.

Environment

• Claude Desktop 2.2553.1 (installed 2026-09-18 00:51 local), bundled engine 2.1.275
• macOS 26.6.2 (Darwin 25.6.0)

Observations

• Prompt suggestions missing in every Code-tab session, not a single one.
• No promptSuggestionEnabled key in the user settings file; CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION is unset in the session environment.

Where the host decides, in 2.2553.1

The feature is still present in the shipped code; it is gated host-side. In app.asar:

resolveGatedSdkSnapshot(){return{..., promptSuggestions:t.xI("162211072"), ...}}
// later, when spawning the engine:
promptSuggestions: le.promptSuggestions ? !0 : void 0

In the bundled engine (2.1.275), the emitter returns early unless the host passed that option:

afterResult(e){if(!this.promptSuggestions()||...||CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION===!1)return; ...

So when gate 162211072 evaluates false for the account, nothing on the client can re-enable it: neither the engine-side tengu_prompt_suggestion flag nor the env var nor promptSuggestionEnabled reaches that check. That fits the reports above where tengu_prompt_suggestion: true is cached and suggestions are still absent.

A one-line statement on whether gate 162211072 is intentionally off (rollout change) or misevaluating would settle this thread.