CLAUDE_CODE_WORKFLOWS env var silently gates the workflows feature even when tengu_workflows_enabled is true (same pattern as #50083)

Binary analysis of v2.1.150 surfaces a second instance of the env-var-plus-flag co-dependency we already track in #50083 (CLAUDE_CODE_MAX_CONTEXT_TOKENS requiring DISABLE_COMPACT). This one affects the workflows feature.

The gate (extracted from the v2.1.150 binary, with minified identifiers preserved verbatim):

function RB() {
  if (JM$ !== void 0) return JM$;
  if (!uH(process.env.CLAUDE_CODE_WORKFLOWS)) JM$ = !1;
  else JM$ = v$("tengu_workflows_enabled", !0);
  return JM$;
}

The function returns false and short-circuits before it ever consults the GrowthBook flag tengu_workflows_enabled. If CLAUDE_CODE_WORKFLOWS is unset (or falsy) in the user's env, the flag's default-true value is unreachable — the feature is off regardless. Same logic is present in v2.1.148 (function renamed LB, minified identifiers different, semantics identical), so this isn't a v2.1.150 regression — it's a longstanding gate that hasn't been documented.

Observable user impact: anyone who relies on the GrowthBook default to enable workflows will see it as off, with no signal as to why. There's no log line, no warning, no "feature unavailable because X" diagnostic. It just isn't there. Support-trap shape is identical to #50083's CLAUDE_CODE_MAX_CONTEXT_TOKENS issue, where users who set the env var without DISABLE_COMPACT got silent no-ops.

Suggested fix (same as the #50083 thread): either collapse the gate to a single source of truth, or document the env-plus-flag pair explicitly with a diagnostic when the user clearly intended the feature on but one half is missing.

Why this matters as a pattern: this is now two confirmed instances of the same anti-pattern in the shipped CC binary. Treating each one individually is whack-a-mole; the underlying issue is the env-then-flag short-circuit shape itself, which makes any default-true GrowthBook flag operationally meaningless when paired with an env-var prerequisite. Worth a categorical look at gating patterns in the codebase.

Credit to @X-15 for the original binary-decompilation work on #50083 that established this analysis pattern for the community.