The Workflow tool has a second command mode built in but unreachable; passing a run id is rejected.
An entire runId-driven workflow mode with its own prompts and rendering routes through an accessor returning undefined.
What's wrong with this entry?
The Workflow tool has gained an entire second mode driven by a runId input: extra input fields, an extra result status, a v2 script description, its own consent prompt, custom result rendering and a background-task handle that pause and stop can kill. Every one of those paths goes through a single accessor whose whole body returns undefined, so none of it is reachable. Passing a runId today is rejected with "runId is not a field of this tool here.", and the permission prompt always falls back to "Review dynamic workflow before running".
- The extra input fields, the extra status value and the consent text are all supplied by that accessor, so with it returning nothing the schema and the summary/render paths take their old branches.
- Nothing in the build ever assigns the background-run handle; the only code that touches it is pause, kill and a background-task check.
- The tool's input schema also contains a spread of a compiled-out constant, meaning a further field was stripped at build time.
- None of these strings exist in 2.1.238; the widened error message is the only visible trace.
runId is not a field of this tool here., Must provide script, name, scriptPath, or runId
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.246
Workflow pattern-matching words and a budget-starvation protocol
Both mention workflow
-
v2.1.246
Internal fact store gains variable binding, threshold triggers and budgets
Both mention workflow
-
v2.1.247
Workflow agents are cut off when they run past their token ceiling
Both mention workflow