autoDreamEnabled is documented as overriding the server-side default, but is silently ignored when the rollout flag is closed

Summary

The autoDreamEnabled setting describes itself as overriding the server-side default. It does not. The rollout-flag availability check is evaluated before the setting is read, so on an account where the flag is closed, setting autoDreamEnabled: true is a silent no-op — with no feedback from /memory, claude doctor, or logs.

This costs real debugging time, because every observable signal points at a configuration problem rather than an entitlement one.

Environment

• Claude Code 2.1.228 (native install, macOS 15 / darwin 24.6.0)
• Team-tier seat, auto-memory enabled and actively writing

The documented contract

From the settings schema shipped in the binary:

autoDreamEnabled — "Enable background memory consolidation (auto-dream). When set, overrides the server-side default."

"Overrides the server-side default" reads as: my explicit setting wins. It doesn't.

Actual behaviour

Reading the shipped bundle (minified; function names are from the build, quoted verbatim so they can be located):

function oap(){ return ot("tengu_onyx_plover", null) }
function Toa(){ let e = oap(); return e?.enabled === !0 || e?.available === !0 }

function pWo(){
  if (!Toa()) return !1;                 // <-- availability gate, evaluated FIRST
  let e = Ho().autoDreamEnabled;         // <-- setting only read if the gate passed
  if (e !== void 0) return e;
  return oap()?.enabled === !0;
}

So when the flag yields neither enabled: true nor available: true, pWo() returns false before autoDreamEnabled is ever consulted. The runner gate ends in return pWo(), so the consolidation pass returns immediately.

Reproduction

1. Confirm the flag is closed for your account:

``
jq '.cachedGrowthBookFeatures.tengu_onyx_plover' ~/.claude.json
``

On this machine: {"enabled": false, "minHours": 24, "minSessions": 3, "remoteEnabled": false} — note it ships the rollout parameters while the enable bit is off, which makes it look configured.

1. Set "autoDreamEnabled": true in ~/.claude/settings.json.
2. Run claude doctor — it reports nothing about the setting (verified: no warning, no "ignored", no mention).
3. No consolidation ever runs. There are no *dream* / *consolidat* state files anywhere under ~/.claude — no .consolidate-lock, no last-consolidated marker. (This part I observed directly.)

In the /memory dialog the Auto-dream row and its toggle handler are both gated on the same availability value, so I believe the row does not render at all on a closed-flag account — but I am reporting that from reading the bundle, not from seeing the UI, since I have no account where I can compare.

What I'd expect

Any one of these would have saved the debugging time — in rough order of preference:

1. claude doctor warns that autoDreamEnabled is set but has no effect on this account, and says why.
2. The schema description is corrected — e.g. "Overrides the server-side default where auto-dream is available for your account." This alone would be enough.
3. /memory shows the row in a disabled state with a reason ("not available for this account"), rather than hiding it — hidden is indistinguishable from "I haven't found it yet".

Why this is worth a fix even though it is a rollout gate

I am not asking for the flag to be opened. The problem is purely that a documented, user-settable, silently-inert setting gives no signal. A user who sets it reasonably concludes their config is broken and goes looking — through settings precedence, /doctor, reinstalls — for a cause that isn't there.

Related

• #76186 notes autoDreamEnabled is undocumented. This is a distinct and stronger claim: it is documented in the settings schema, and the documentation is inaccurate about precedence.
• #59885 (closed) shows another user hitting the same entitlement gate from the other direction.
• #38461 reports the toggle being ON without a background task starting, which may be the same gate seen from an account where the row is visible.