A migration’s author and reviewer need different powers. Qwen Code’s September 12 workflow change, included in v0.23.4, adds effort and disallowedTools to the script’s agent(prompt, options) API. It is an API inside Qwen’s Workflow tool, not an HTTP endpoint or a standalone JavaScript library.
A practical example
After an implementation pass, give a reviewer a fixed list of changed files and ask it to find incompatible configuration migrations. This minimal step removes the built-in shell, write and edit tools while requesting high reasoning effort:
const review = await agent(
"Inspect the listed migration files. Report compatibility risks " +
"with file references. Do not change files: " + args.files.join(", "),
{
label: "migration-review",
effort: "high",
disallowedTools: ["run_shell_command", "write_file", "edit"]
}
);
if (review === null) throw new Error("Review did not complete");
return review;
The authoring reference requires plain JavaScript, an explicit return, and a workflow the user has opted into. Pass args.files as an array. Tool denials add to the existing restrictions; they cannot restore a forbidden tool. This short list blocks three tools, not every possible way to mutate a system. Check installed tools and deny relevant MCP tools too before treating the review as read-only.
Copy-paste agent instruction
Prepare a Qwen Code workflow for reviewing my migration diff.
First list the files and inspect the registered tools. Give the
reviewer high effort, deny shell/write/edit, and add every relevant
mutating tool or MCP server to its deny list. Keep the current model.
If you cannot establish that tool scope, stop and explain the gap.
Pass the file list through args.files. Treat a null result as failure.
Show me the script and get my workflow opt-in before running it.
Do not edit files or change configuration as part of this review.
The useful catch
The resume tests verify that changing effort or denied tools changes the stored-result key. Reordering an equivalent list should not. That prevents a newly restricted review request from silently accepting a result obtained under different options.
What to check before running it
We inspected the implementation, tests and released reference; we did not execute this workflow or test a provider account. Effort depends on the model’s supported tiers and settings, and does not force thinking on when disabled. A deny list is not operating-system isolation. The first useful trial is one small diff, followed by checking the actual tool calls and whether the requested restrictions reached the reviewer.