Workflow({name}) does not discover saved workflows under .claude/workflows/, contradicting the tool description

Workflow({name}) doesn't discover saved workflows under .claude/workflows/, contradicting the tool's own description

Summary

The Workflow tool's parameter description for name states:

Name of a predefined workflow (built-in or from .claude/workflows/).

In practice, calling Workflow({ name: '<workflow-name>' }) for a workflow that exists as .claude/workflows/<workflow-name>.mjs in the current repo fails, and the error's "Available" list only contains harness built-ins:

Available: deep-research, code-review

Repro

1. In a repo with a project-local saved workflow at .claude/workflows/my-workflow.mjs (any valid workflow script with a proper export const meta = { name: 'my-workflow', ... } header).
2. Call Workflow({ name: 'my-workflow', args: {...} }).
3. Observe the error listing only deep-research, code-review as available — the on-disk workflow is never discovered, even though it exists, is syntactically valid, and its meta.name matches the requested name exactly.
4. Calling the same script via Workflow({ scriptPath: '.claude/workflows/my-workflow.mjs', args: {...} }), or via Workflow({ script: <file contents>, args: {...} }), does successfully run the script — confirming the file itself is valid and the gap is specifically in name-based registry lookup. (Note: scriptPath has its own separate bug on Windows CRLF checkouts — see the companion issue filed alongside this one — so script: inline is the most reliable way to confirm this.)

Expected

Workflow({ name: ... }) should resolve project-local workflows under .claude/workflows/*.mjs (matching on their meta.name field), not just the two harness built-ins, per the tool's documented behavior.

Impact

This breaks any documented recipe that instructs users/agents to invoke a saved workflow by name (e.g. a project's CLAUDE.md or a custom skill that says Workflow({ name: 'my-workflow', args: ... })) — the call fails every time, and the only working alternative is to fall back to reading the file and calling Workflow({ script: <contents>, args: ... }) inline, which defeats the purpose of saving a named workflow at all.

Environment

• OS: Windows 11 (though this looks environment-independent — a pure registry/discovery gap)
• Workflow tool available via Claude Code / Agent SDK