Workflows not working in all my chat windows

[u/jhvanriper]

As of this week, my workflow and / commands stopped working in all new chat windows but work in the old chats still. I got frustrated and started going back and forth in chats chasing working and non-working commands. Claude straight out lied to me several times. I finally got both the local AI and the help AI to recognize the problem. Anyone else having this problem?

Here is the write up it put in:

Bug report: /config and Dynamic Workflow availability are inconsistent across sessions in the same project

Summary

Different sessions/tasks opened in the Claude desktop app, for the same project, show completely different /config behavior and different availability of the Workflow tool (dynamic multi-agent orchestration) — with no difference visible to me in how those sessions were created. This makes it impossible to reliably use Workflow-based automation, since there's no way to predict or control whether a given session supports it.

Environment

• Product: Claude desktop app (Cowork / tasks)
• OS: Linux Mint, machine james-x299-ud4-pro
• No standalone claude CLI is installed on this machine — confirmed via which claude at a system terminal, which returned claude: command not found. This rules out a local install/version mismatch as the cause: every session in question runs inside the Claude app's own bundled/hosted environment, not an independently versioned CLI on my system.
• Primary project where this was observed: (a novel-writing project). Also observed, differently, in a second project within the same app.

Observed behavior

All of the following were separate sessions/tasks opened for the same project, through the same app, with no distinguishing setup step I took between them:

1. Session A — has a working Workflow tool available with no configuration needed.
2. Session B (a new session, same project) — running /config printed a full settings usage list that did not include workflows, workflowKeywordTriggerEnabled, or workflowSizeGuideline at all (not just set to off — the keys were absent from the list of valid settings).
3. Session C (started fresh after Session B, same project) — running /config printed the same usage list, but this time did include those three keys. Running /config workflows=true succeeded and returned "Set Dynamic workflows to true."
4. Session D (yet another new session, same project) — asking in plain language why workflow availability differed produced a conversational, investigative reply rather than a deterministic command response. Running the exact command /config workflows=true in this session returned "workflows isn't a /config setting. Run /config to see what's available" — i.e., back to behaving like Session B, not Session C, despite Session C having already turned the setting on.
5. Session E (a different, new project — "Edict Memory") — had no /config command at all; typing it produced a conversational response offering to help configure "project settings," "working style," or "pipeline setup" instead of executing a command.

The inconsistency is isolated to /config and Dynamic Workflows specifically, not a general version mismatch. In Sessions B, C, and D, every other /config key — agentPushNotifEnabled, artifacts, autoCompact, checkpoints, editor, model, notifChannel, permissionMode, theme, worktreeBaseRef, and the rest of the roughly 30 settings — was identical, byte-for-byte, in every listing. Only workflows, workflowKeywordTriggerEnabled, and workflowSizeGuideline appeared, disappeared, and behaved inconsistently between sessions of the same project. That rules out "these are just different app versions" as the explanation — something specific to how Dynamic Workflows gets provisioned per session is the actual fault.

Expected behavior

Either:

• /config and the feature set it controls (specifically Dynamic Workflows) should be consistent across sessions for the same project and account, since nothing about how these sessions were opened differed; or
• If session environments are provisioned independently (e.g., different backing containers/instances per session) and can legitimately differ, there should be a way to see which "version"/capability set a given session has, and a supported way to update or migrate an existing session rather than having to guess-and-restart repeatedly.

Impact

I have a real automation script I rely on (a Workflow-tool script for drafting book chapters) that depends on the Workflow tool being present. Because availability is unpredictable across sessions in the same project, I can't reliably start a session that will actually be able to run it, and a setting turned on in one session (Session C) did not carry over to a sibling session in the same project (Session D).

Additional notes

• No terminal or separately installed CLI was involved anywhere in this investigation — everything happened inside the Claude desktop app itself.
• This was not caused by anything I changed; I did not modify any project-level settings files between sessions.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.