feat(computer-use): configurable screenshot max dimension (setting + env)#5122
Conversation
…env)
Add a user-level knob for cua-driver's screenshot longest-edge cap. The
old open-computer-use backend exposed this via OPEN_COMPUTER_USE_IMAGE_*
env vars; the cua-driver migration dropped them, leaving only the
model-driven set_config tool. This restores deterministic user control.
- Setting tools.computerUse.maxImageDimension (number; default -1 = keep
cua-driver's built-in default of 1568; 0 disables resizing / full
resolution; a positive value caps the longest edge).
- Env override QWEN_COMPUTER_USE_MAX_IMAGE_DIMENSION (takes precedence
over the setting; invalid/negative values fall through).
- Resolution lives in resolveMaxImageDimension(); applied via the
cua-driver set_config tool once per (re)connect in
ComputerUseClient.doStart — best-effort, never aborts startup, and
re-applied after a daemon-restart reconnect.
- Docs: document tools.computerUse.{enabled,maxImageDimension} in
settings.md (the block was previously undocumented). Refresh stale
ocu/npx comments left in client.ts + install-state.ts by the migration.
Precedence: env var > setting > cua-driver default.
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Hey @LaZzyMan — thanks for the PR! The feature itself looks useful, but the PR body is missing several required sections from the PR template. The current headings (What, How, Docs (req. 3), Testing) don't match the template structure.
Missing sections:
- Why it's needed — the motivation / user-facing benefit. The "How" section explains implementation but not the why.
- Reviewer Test Plan — how a reviewer can confirm this works. Needs
How to verify,Evidence (Before & After), andTested on(OS table). The "Testing" section lists unit test coverage but doesn't tell a reviewer how to verify the feature end-to-end. - Risk & Scope — main risk/tradeoff, what's out of scope, breaking changes.
- Linked Issues — related issues or PRs (e.g. the #5051 follow-up you mention).
Could you update the body to follow the template? It helps reviewers move faster and catches things like untested platforms or undocumented risks.
中文说明
@lazyyman 你好,感谢提交!这个功能本身很有用,但 PR 正文缺少 PR 模板 中的几个必需章节。当前标题(What、How、Docs (req. 3)、Testing)与模板结构不匹配。
缺少的章节:
- Why it's needed — 动机和用户价值。"How" 章节解释了实现方式,但没有说明 为什么 需要这个改动。
- Reviewer Test Plan — 审核者如何确认功能正常。需要包含
How to verify、Evidence (Before & After)和Tested on(操作系统表格)。"Testing" 章节列出了单元测试覆盖,但没有告诉审核者如何端到端验证功能。 - Risk & Scope — 主要风险/权衡、不在范围内的内容、破坏性变更。
- Linked Issues — 相关 issue 或 PR(例如你提到的 #5051 后续)。
请按照模板更新 PR 正文,这样可以帮助审核者更快地完成审查。
— Qwen Code · qwen3.7-max
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
The cua-driver migration (#5051) left scripts/sync-computer-use-schemas.ts pointing at the old open-computer-use backend: it npx'd @qwen-code/open-computer-use, hard-coded the 9-tool ocu surface, and emitted an "open-computer-use" header. Re-running it — which constants.ts' version-bump procedure tells maintainers to do — would have clobbered the migrated 35-tool cua-driver schemas.ts. - Drive the locally-pinned `cua-driver mcp` binary (binaryPath / CUA_DRIVER_VERSION from constants.ts) instead of npx'ing ocu; expect 35 tools and warn (don't fail) on drift. - Emit the cua-driver-flavored schemas.ts header. - Refresh install-state.test.ts fixtures from ocu package specs to the cua-driver-rs approval-key form the field actually stores now. Verified the fixed script reproduces the committed 35-tool surface exactly (modulo prettier formatting). No dead env-var handling remained — the module reads only QWEN_COMPUTER_USE_{AUTO_APPROVE,DOWNLOAD_HOST,MAX_IMAGE_DIMENSION}.
|
Qwen Code review did not complete successfully: Qwen review aborted with an API error before posting comments. See workflow logs. |
|
Restructured the PR body to follow the template — added Why it's needed, Reviewer Test Plan (How to verify · Evidence before/after with the 400→400×231 / 1200→1199×693 pixel measurements · Tested-on OS table), Risk & Scope, and Linked Issues (#5051). The earlier |
Live e2e verification reportBeyond the unit tests, I verified the feature end-to-end against a real cua-driver 0.5.2 binary on macOS (arm64) — driving the actual Test 1 —
|
maxImageDimension |
resulting screenshot | longest edge |
|---|---|---|
400 |
400×231 | 400 ✅ |
1200 |
1199×693 | 1199 ✅ (aspect ratio preserved) |
1800 / 4.5 = 400, 1040 / 4.5 = 231; 1800 / 1.5 = 1200, 1040 / 1.5 = 693 — the longest edge is capped exactly at the configured value, aspect ratio intact.
Verification matrix
| Link | How verified |
|---|---|
| settings.json → CLI Config → tool resolve (env > setting > default) | unit tests |
tool → client.setMaxImageDimension |
unit test |
applyRuntimeConfig → set_config arg |
unit test |
real client.start() → live driver set_config |
e2e (disk, Test 1) |
| config value → real screenshot pixels capped | e2e (Test 2) |
Scope / caveats (honest)
- Live measurement was macOS-only — the resize is driver-side and platform-independent, but I only had a Mac to measure on. Windows/Linux are covered by the CI unit tests.
- A full model-driven CLI session (settings.json → live model turn) was not e2e'd; this exercised the client + driver directly.
- Test-harness note: my ad-hoc client spawned a
cua-driver mcpproxy that initially routed to a daemon without the Screen Recording grant (screenshots failed);CUA_DRIVER_RS_MCP_FORCE_PROXY=1pointed it at the granted daemon. In real qwen-code the bootstrap grants permission to the proxy's daemon, so this is a harness artifact, not a feature issue.
wenshao
left a comment
There was a problem hiding this comment.
No review findings. Downgraded from Approve to Comment: CI failing (review-pr). — qwen3.7-max via Qwen Code /review
|
Qwen Code review did not complete successfully: Qwen review aborted with an API error before posting comments. See workflow logs. |
|
Reviewed the full diff and cross-checked against cua-driver's actual 1. Clearing the setting won't reset the driver back to 1568. Since 2. (nit) Reconnect noise. During the macOS-grant daemon restart, Nothing blocking — nice cleanup of the ocu → cua-driver leftovers too. 中文通读了完整 diff,并和 cua-driver 真实的 1. 清除该设置不会把 driver 复位回 1568。 因为 2.(nit)重连噪音。 在 macOS 授权触发的 daemon 重启窗口里, 没有阻断项——顺手清掉 ocu → cua-driver 的历史残留也很赞。 |
What this PR does
Adds a user-level knob for the cua-driver screenshot longest-edge cap — both a
tools.computerUse.maxImageDimensionsetting and aQWEN_COMPUTER_USE_MAX_IMAGE_DIMENSIONenvironment variable. The value is resolved (env > setting > driver default) and pushed to cua-driver via itsset_configtool on every (re)connect.It also finishes the open-computer-use (ocu) → cua-driver cleanup the migration left behind: rewires the stale
scripts/sync-computer-use-schemas.tsregenerator (it still npx'd@qwen-code/open-computer-useand hard-coded the 9-tool ocu surface) to drive the localcua-driver mcpbinary, and refreshes ocu-flavored test fixtures + comments.Why it's needed
The old open-computer-use backend let users cap screenshot size globally via
OPEN_COMPUTER_USE_IMAGE_*env vars. The cua-driver migration (#5051) dropped them, leaving only the model-drivenset_configMCP tool — so there was no deterministic, user-controlled way to bound screenshot resolution. The longest-edge cap is the main lever for cutting vision-token cost (and latency) in computer-use sessions; without a user knob, every screenshot ships at cua-driver's 1568px default.Reviewer Test Plan
How to verify
tools.computerUse.maxImageDimension: 400insettings.json(orexport QWEN_COMPUTER_USE_MAX_IMAGE_DIMENSION=400).get_window_state).0= full resolution;-1/unset = driver default. The env var takes precedence over the setting; invalid/negative values fall through.Evidence (Before & After)
Measured a real 1800×1040 window through the actual
ComputerUseClientagainst live cua-driver 0.5.2:1568(default)4001200Also disk-verified that
client.start()drivesset_configinto the daemon —~/.cua-driver/config.jsonwent1568 → 512after a real client start with the override.Tested on
Environment (optional)
Local pinned cua-driver 0.5.2 binary (macOS arm64) +
npx vitest. The resize is driver-side and platform-independent, so the live pixel measurement was done on macOS only.Risk & Scope
set_configis applied best-effort on connect — a failure is logged via the progress stream and swallowed, never aborting startup (the driver stays usable at its default dimension). Costs one extra MCP round-trip per (re)connect, and only when an override is configured.0(no-limit) branch is unit-tested but not pixel-measured.-1(= keep cua-driver's built-in 1568), so default behavior is unchanged.Linked Issues
Follow-up to #5051 (the open-computer-use → cua-driver migration).