One helper now decides whether workflows are off, covering the setting, env var and remote gate.
tengu_workflows_enabled Off by default, switched on for this accountThe shipped code defaults this off, and the flag server returned on for the one account this site reads on this version. That is the reading that makes the entry above worth a second look, and it still says nothing about your account.
This account: on · anonymous baseline: on · compiled default in v2.1.234: off
Read once, for one account on one subscription tier, against v2.1.234. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
A single helper now answers whether workflows are disabled, covering the entitlement check, the enableWorkflows user setting being false, CLAUDE_CODE_WORKFLOWS set to false, and the remote tengu_workflows_enabled gate (fallback true). Workflow warm-up returns early when it says so.
- Any one of the four conditions is enough to disable workflows; previously these checks were spread across call sites.
tengu_workflows_enabled
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.221
PR review artifacts can carry an "Approve on GitHub" button
Both mention enable
-
v2.1.242
Enabling a plugin now fails when its dependencies are disabled
Both mention enable
-
v2.1.248
Telemetry enablement read through a helper
Both mention enable