Commit 92ee722

name: 'Android Mobile Shell'

on:

pull_request:

paths:

- '.github/workflows/mobile-shell.yml'

- 'packages/mobile-shell/**'

- 'scripts/check-desktop-isolation.js'

push:

branches:

- 'main'

paths:

- '.github/workflows/mobile-shell.yml'

- 'packages/mobile-shell/**'

- 'scripts/check-desktop-isolation.js'

workflow_dispatch:

permissions:

contents: 'read'

jobs:

validate:

name: 'Build, unit tests, and lint'

runs-on: 'ubuntu-latest'

timeout-minutes: 20

defaults:

run:

working-directory: 'packages/mobile-shell'

steps:

- name: 'Checkout'

uses: 'actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10' # v6.0.3

- name: 'Set up Java 17'

uses: 'actions/setup-java@cf277c60eb25467037889841efdb72551f06f6c3' # v4

with:

distribution: 'temurin'

java-version: '17'

- name: 'Verify Gradle wrapper'

shell: 'bash'

run: |

- name: 'Build, run unit tests, and lint'

shell: 'bash'

run: './gradlew --no-daemon assembleDebug testDebugUnitTest lintDebug'

- '!packages/mobile-shell/package.json'

- '!packages/mobile-shell/package.json'

- A checkpoint stall streak. (Historical: since the verifier judges a proposal

from the transcript tail directly, `update_goal` no longer answers

`checkpointRequired` and no checkpoint runs; the stall streak stays at zero.)

A model that fills the evidence window with prose

checkpoint's, and `update_goal` used to answer `checkpointRequired` on an

[中文](./2026-09-17-workflow-name-only.zh-CN.md)

Tracking issue: #11013, item 12 (remaining part).

Status: implemented in #12078.

A deployment can let the model start the workflows an extension ships (`whenToUse`, #11957) and can scope approvals to a workflow by name or path (#11943). It had no way to stop the same model from writing an inline script of up to 1,000 agents and running it. An inline script has no name or path to write a permission rule against, so once a deployment relaxed approvals for its named workflows, inline scripts went through as well.

`tools.workflowNameOnly` (default `false`) or `QWEN_CODE_WORKFLOW_NAME_ONLY=1` turns the lock on. `Config.isWorkflowNameOnly()` decides it once, when the session starts: the Workflow tool builds its description and parameter schema at startup, and a lock that changed under them would leave the model holding a contract the tool no longer honours.

A workspace may turn the lock on but not off. The key is a tighten-only setting: a workspace `true` is honoured, and a workspace `false` under an operator's `true` is dropped with a warning. The environment variable is excluded from project `.env` files, so repository content cannot unset an operator's exported value.

| Source | Locked session | Why |

| ------------------------------------------------------------ | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |

| `script` | refused | Code the model writes in the session has no identity a rule can match. |

| `scriptPath` | refused | Every saved workflow is reachable by name; a path adds nothing a name cannot say, and the generated-scripts root is a runtime directory. |

| `name`, and `name` with `resumeFromRunId` | allowed | A `Workflow(name:…[,sha256:…])` rule matches it. |

| `workflow({ scriptPath })` inside a script the model started | refused | The same rule, one level down. `workflow('<name>')` still works. |

A source counts the way parameter validation counts it: an empty `script` or `scriptPath` beside a `name` does not refuse a call that runs by name.

The refusal sits in the tool's `build`, the entry every model and client call takes, including the interactive slash command's `schedule_tool`. Runs a host starts over ACP — `run-saved`, `run-script`, retry and rerun — go through `buildSessionOwnedBackground`, which shares parameter validation but not `build`, and are not restricted. The nested refusal follows the same line: the tool asks the runner for it only on a call it built for the model or a client, so a host script may still nest by path.

A locked session tells the model the rule instead of letting it find the rule by failing:

- The parameter schema omits `script` and `scriptPath`. `name` is not made `required`, because the host's runs validate against the same schema and start from a script.

- The description replaces the authoring pointer with a "Named workflows only" section, and its shared decision and runtime text lose the sentences that send the model to `scriptPath` or to editing a persisted script. A test holds that no such advice survives outside the section.

- The `workflow` keyword reminder steers toward `{ name, args }` instead of authoring a script. The lock is read before anything else in that path can fail.

- The interactive `/<name>` command dispatches by name.

Outside the lock, resume calls keep naming the script path, so existing `Workflow(scriptPath:…)` grants keep matching. In a locked session a path is refused, so the resume call names the workflow — but only a name that leads back to the script the run executed. A workflow name can be recorded from a path in a subdirectory, from a user workflow a same-named project workflow shadows, or carried over by a retry that fell back to the run's inline copy; resuming by such a name would run a different script, or none. The runner therefore resolves the name once, as the run starts, and records it as the run's `resumeName` only when it resolves to the same file. A run without one gets no resume call; its failure notice says that only whoever started it can retry it.

The lock itself lives in one place, the Config. The Config hands it to the workflow run registry it owns, which reads it when a notification offers a resume call; the tool and the keyword reminder read the Config.

`workflowToolFeatures.nameOnly` in `GET /session/:id/supported-commands` reports the lock, so a host knows the model is restricted while its own `run-script` still starts runs.

Claude Code's `CLAUDE_WORKFLOW_NAME_ONLY` refuses `script`, `scriptPath` and `resumeFromRunId`, limits resolution to built-in workflows, and refuses a nested `workflow({ scriptPath })` for every run. Qwen Code has no built-in workflows, and the lock serves deployments that start named runs and resume them, so it keeps every name tier (project, user, extension), allows a named resume, and leaves host-started runs unrestricted.

The tighten-only merge compared a workspace value against the stricter of User and SystemDefaults, while the merge lets User override SystemDefaults. With SystemDefaults stricter and User looser, a workspace value equal to SystemDefaults was dropped as "no change" although the value in force was User's. The baseline is now the value in force without the workspace: User's when User sets the key, otherwise SystemDefaults', otherwise the default. This also affects `agents.crossSessionMessaging` and `agents.crossSessionInbound`.

- The lock makes every run the model starts addressable by a name rule; it does not approve or block anything by itself. The model can still save a new workflow file and run it by name, which an approval rule scoped to specific names or script digests will ask about.

- In a locked session the `/review` workflow fan-out is unavailable, because it runs a generated script by path. The review skill already reports an unavailable tool and stops.

- The resume name is checked when a run starts. A workflow file added or removed afterwards is not reflected.

- A bundled `deep-research` workflow (the other remaining part of item 12).

- An allowlist of name sources.

- Changing the lock during a session.

- Unit tests cover each refused and accepted source, the host runs (script, script path, nested path), the schema and description shapes, the resume name when it matches and when it does not, the notices, the keyword reminder when the registry throws, the slash command, the Config's start-time decision, the tighten-only baseline for this key and for `crossSessionInbound`, and the ACP flag.

- Hand-made mutations of each new branch fail at least one test.

[English](./2026-09-17-workflow-name-only.md)

跟踪 issue：#11013 第 12 项（剩余部分）。

状态：已在 #12078 实现。

部署方可以让模型启动扩展随包发行的 workflow（`whenToUse`，#11957），也可以按名字或路径限定审批（#11943），但没有办法阻止同一个模型自己写一段最多 1000 个 agent 的内联脚本来运行。内联脚本没有可写权限规则的名字或路径，部署方一旦为命名 workflow 放宽审批，内联脚本也会一并放行。

`tools.workflowNameOnly`（默认 `false`）或 `QWEN_CODE_WORKFLOW_NAME_ONLY=1` 打开锁。`Config.isWorkflowNameOnly()` 在会话启动时确定一次：Workflow 工具在启动时构建描述和参数 schema，锁若在会话中途变化，模型手里的契约就与工具实际行为不一致。

工作区可以打开锁，不能关闭。该键是"工作区只能收紧"的设置：工作区的 `true` 生效；操作者设为 `true` 时，工作区的 `false` 会被丢弃并告警。环境变量不允许由项目 `.env` 设置，仓库内容无法取消操作者导出的值。

| 来源 | 锁开时 | 理由 |

| --------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------ |

| `script` | 拒绝 | 模型在会话里写的代码没有可被规则匹配的身份。 |

| `scriptPath` | 拒绝 | 每个已保存 workflow 都能按名字到达；路径提供不了名字之外的东西，generated-scripts 根目录是运行期目录。 |

| `name`，以及 `name` 加 `resumeFromRunId` | 允许 | 可被 `Workflow(name:…[,sha256:…])` 规则匹配。 |

| 模型启动的脚本里的 `workflow({ scriptPath })` | 拒绝 | 同一条规则的下一层。`workflow('<name>')` 照常。 |

来源的判定与参数校验一致：`name` 旁边为空的 `script` 或 `scriptPath` 不会让一个按名运行的调用被拒。

拒绝放在工具的 `build` 里，模型和客户端的每次调用都经过这里，包括交互斜杠命令的 `schedule_tool`。宿主经 ACP 发起的 `run-saved`、`run-script`、retry、rerun 走 `buildSessionOwnedBackground`，与 `build` 共用参数校验但不经过 `build`，不受限制。嵌套拒绝也按同一条线划分：只有工具为模型或客户端构建的调用才会要求 runner 拒绝，宿主的脚本仍可按路径嵌套。

锁开的会话直接把规则告诉模型，而不是让它撞错才知道：

- 参数 schema 去掉 `script` 与 `scriptPath`。`name` 不设为必填，因为宿主的运行复用同一份 schema 校验，并从脚本启动。

- 描述用 "Named workflows only" 一段替换 authoring 指针，共享的决策与运行时文字去掉引导模型使用 `scriptPath` 或编辑已落盘脚本的句子。有测试保证这类说法不会在该段之外残留。

- `workflow` 关键词提醒引导 `{ name, args }`，不再引导写脚本。锁状态在该路径里任何可能失败的步骤之前读取。

- 交互 `/<name>` 命令按名调度。

锁关时，恢复调用仍给出脚本路径，已有的 `Workflow(scriptPath:…)` 授权继续匹配。锁开时路径被拒，恢复调用改为给出 workflow 名，但只给能回到本次运行所执行脚本的名字。workflow 名可能来自子目录里的文件路径、来自被同名项目 workflow 遮蔽的用户 workflow，或是 retry 回退到内联副本时沿用的旧名；按这样的名字恢复会运行另一个脚本，或者找不到脚本。因此 runner 在运行启动时解析一次该名字，只有解析到同一个文件时才记为该运行的 `resumeName`。没有 `resumeName` 的运行不提供恢复调用，失败通知说明只能由启动方重试。

锁本身只存在于一处：Config。Config 把它交给自己持有的 workflow 运行 registry，registry 在通知里给出恢复调用时读取；工具和关键词提醒读 Config。

`GET /session/:id/supported-commands` 的 `workflowToolFeatures.nameOnly` 反映锁状态，宿主据此知道模型受限，而自己的 `run-script` 仍能启动运行。

Claude Code 的 `CLAUDE_WORKFLOW_NAME_ONLY` 拒绝 `script`、`scriptPath` 和 `resumeFromRunId`，只解析内置 workflow，并对所有运行拒绝嵌套的 `workflow({ scriptPath })`。Qwen Code 没有内置 workflow，而这个锁面向的是启动命名运行并恢复它们的部署，所以保留全部名字层级（项目、用户、扩展），允许按名恢复，并且不限制宿主发起的运行。

"工作区只能收紧"的合并逻辑把工作区的值与 User、SystemDefaults 中更严的那个比较，而合并时 User 覆盖 SystemDefaults。当 SystemDefaults 更严、User 更松时，与 SystemDefaults 相同的工作区值会被当成"没有变化"丢弃，尽管实际生效的是 User 的值。现在的基线是不含工作区时实际生效的值：User 设置了就用 User 的，否则用 SystemDefaults 的，否则用默认值。这一修复同样影响 `agents.crossSessionMessaging` 与 `agents.crossSessionInbound`。