fix(cli): never honor memory agent budgets from workspace scope - #13508

Partially reviewed — gaps disclosed. Suggestions are inline.

Not reviewed: reverse audit — stopped before round 3 by the review time budget.

— qwen3.8-max via Qwen Code /review (v0.25.0)

Critical-only scan at head 9cd07ab29ea0148ace1ef6ee1e2389da57f1d1a4 — complete. Verdict: APPROVE.

No Critical found, and this PR has no historical blocking issue to clear: the only review round on it filed four findings, all severity S, and all four inline threads are resolved with zero unresolved. Under this channel's Critical-only policy those Suggestions are read but not tracked, and nothing in them bears on merge.

The diff is description strings, the docs row that mirrors them, the regenerated VS Code schema, and two test changes. That surface has one way to be wrong — describing a protection that does not exist — so that is what I checked first.

The scope sentence describes a restriction that is live at this head

Both descriptions now end with User/System/SystemDefaults scopes only; Workspace values are ignored with a warning. The body states the enforcement itself landed on main via #13462 and that this diff therefore carries no settingsUtils.ts change. Verified rather than taken: packages/cli/src/config/settingsUtils.ts at this head holds { section: 'memory', key: 'agentMaxTurns' } and { section: 'memory', key: 'agentTimeoutMinutes' } inside WORKSPACE_RESTRICTED_SETTINGS (:280-281). That list drives both the pre-merge Workspace strip and the "ignored" warning from a single source, so the string an operator reads in VS Code while completing **/.qwen/settings.json now agrees with what the runtime actually does to that file's value. The replaced wording — "Configure in user or system settings." — both omitted a scope that is honored and never said the value is dropped, so this is a correction rather than a restatement.

The five-consumer enumeration is accurate, and the asymmetry between the two keys is deliberate

agentTimeoutMinutes gains a fifth governed consumer, the memory metadata migration, while agentMaxTurns keeps four. I confirmed the split is factual rather than an oversight: packages/core/src/memory/metadata-migration.ts reads config.getMemoryAgentTimeoutMinutes() ?? 10 at :506 and hardcodes maxTurns: 1 at :505. So the migrator really is governed by the timeout budget and really is not governed by the turn budget, and listing it under only one of the two keys is the correct outcome. docs/users/configuration/settings.md:434 carries the same five-agent enumeration, so the docs row and the schema string agree.

The generated packages/vscode-ide-companion/schemas/settings.schema.json mirrors both settingsSchema.ts descriptions byte-for-byte, which is what the generator contract requires; Test (ubuntu-latest, Node 22.x) is green at this head, so no drift check tripped.

Both test changes hold up

• 0 is a strictly better probe than true was. The list-driven test builds a Workspace payload from WORKSPACE_RESTRICTED_SETTINGS itself, then asserts for every key that merged?.[key] is undefined and that a warning naming section.key exists. stripSettingKeys skips only on source?.[key] === undefined, so feeding 0 exercises the falsy-numeric path a truthiness-based strip would silently pass through — and 0 is the exact value the restriction exists to block, since it disables the limit entirely. A leaked 0 fails toBeUndefined(), so the assertion is not vacuous. The allowedInsecureVoiceBaseUrls array special-case is preserved, and every other key still gets true.
• The membership assertion is redundant by design, not by accident. exposes every key in dotted form for the dialog filter already asserts WORKSPACE_RESTRICTED_SETTING_KEYS equals the list mapped to dotted form, so a toContain for the two memory keys adds no coverage the equality does not. Placing it beside the existing list-driven test rather than in a second describe keeps the three consumers of the list — strip, warning, dialog filter — pinned in one place, which is the point of the R4-3 comment above it. Harmless and consistent with the file's existing shape.

CI

Healthy at this head — Test (ubuntu-latest, Node 22.x), Lint & Static, Integration Tests (no-AK, No Sandbox), Native Windows settings and streams, Native Linux CLI boundary, the OpenTUI no-flicker and TUI parity gates and both Desktop Shell legs pass. web-shell E2E Smoke was still pending at review time; nothing failed and no failure is attributable to this PR.

Changed files sit under packages/cli/src/config/, so require_code_owner_review applies. This approval is submitted as qqqys.

Tier: Scan. Four-file change: two description strings in settingsSchema.ts, their generated mirror in settings.schema.json, the matching docs table row, and a test payload fix. No behavior change — workspace enforcement of both keys ships on main via #13462.

Scope. settingsSchema.ts and settings.schema.json (description strings only), docs/users/configuration/settings.md (matching docs row), settings.test.ts (list-driven payload and membership assertion). settingsUtils.ts is confirmed absent from the net diff against base — the restriction entries are already on main.

Findings

No blocking findings.

Consistency checks

Schema ↔ generated JSON — settings.schema.json is a byte-identical regeneration of the two changed description strings in settingsSchema.ts. Both surfaces carry the full sentence User/System/SystemDefaults scopes only; Workspace values are ignored with a warning. ✓

Schema ↔ docs row — agentTimeoutMinutes: five-agent list (extraction, dream, remember, skill review, memory metadata migration) matches across schema and docs row; scope warning matches. agentMaxTurns: four-agent list (metadata-migration hardcodes maxTurns: 1, correctly excluded) matches; scope warning matches. Pre-existing asymmetry: the schema carries "Useful for slow local models…" but the docs row does not; this is not introduced by this PR. ✓

Test payload — the list-driven strips and warns for every listed key test now feeds 0 for agentMaxTurns and agentTimeoutMinutes rather than true. Both settings are declared type: number, minimum: 0; 0 is the exact value the restriction exists to block and true would silently coerce. ✓

Membership assertion placement — the lists both memory budgets as workspace-restricted check lands inside the existing WORKSPACE_RESTRICTED_SETTINGS describe block rather than in a separate memory agent budget scope handling block (which the second commit removed). The two behavioral cases dropped from that block (honors user-scope 0, strips workspace 0 and warns per key) are already covered by main's it.each([undefined, 0, 25]) pin. ✓

Cross-check — qqqys approved at this exact head after a Critical-only scan; four prior S-level threads from qwen-code-review-bot are all resolved. No misses found — the PR is description-and-test-only with no mechanism to audit beyond consistency.

No blocking findings. Approval blockers: none.

Reviewed with AI assistance.