mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-08-10 17:27:10 +00:00
* fix(cli): probe sandbox runtime before selecting it Sandbox selection treated PATH presence as proof a runtime works, so an installed-but-unusable docker (daemon stopped, socket unreachable, user not in the docker group) was still selected and the podman branch below it became unreachable. Each candidate is now probed with `version` — the cheapest command that still contacts the daemon — and the first one that actually runs wins. When nothing usable is found, the error names the runtime that broke and quotes its failure instead of claiming nothing is installed. An explicit QWEN_SANDBOX choice is never silently redirected; it fails with the daemon error attached. sandbox-exec is not probed, being a kernel facility rather than a daemon client. Fixes #7732 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): attribute the sandbox command to its real source The probe failure hardcoded "(from QWEN_SANDBOX)", but an explicitly named command also arrives from --sandbox or tools.sandbox in settings. Naming the env var unconditionally sends a user who never set it looking in the wrong place — the same misdirection this change set out to remove. The parenthetical is now emitted only when the env var actually supplied the value, which also corrects the pre-existing "Missing sandbox command" message. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): apply source-accurate attribution to the auto-detect errors too The explicit-string path stopped hardcoding QWEN_SANDBOX, but the auto-detect errors still did, so `qwen --sandbox` with a broken runtime pointed at an env var the user never set. Both auto-detect messages now name the env var only when it was what enabled sandboxing, and otherwise suggest --sandbox. Also lowers the probe timeout from 10s to 5s. Probes run sequentially, so the ceiling is paid once per wedged runtime; a healthy `docker version` answers in roughly 200-500ms, so 5s keeps an order of magnitude of headroom while halving the worst-case startup delay. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(cli): assert the sandbox probe argv and timeout The spawnSync stub routed on command name alone, so the probe arguments were never observed. Rewriting the probe to `docker --version` — which prints the client build without contacting the daemon, restoring the original defect — left all 12 tests green, as did deleting the timeout that bounds a wedged daemon. Validate both in the stub, so every probing test carries the check, and pin the argv at the fallback call site where the behavior is asserted. Reported by @wenshao in the mutation matrix on #7734 (M9, M8). * test(cli): cover the empty-output and timeout probe branches Two probe branches in probeSandboxCommand were unpinned, so a mutant in either survived the whole suite: - a non-zero exit with empty output relied on the synthesized-message fallback; dropping it made the probe return undefined and a broken runtime read as usable - the result.error branch that the probe timeout produces had no test; deleting it degraded the error text with the suite still green Each new test fails against its mutant and passes on the real code. Reported by @qwen-code /review on #7734. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(cli): isolate the sandbox probe in config precedence tests The image-precedence tests enable the sandbox and assert only which image wins. Since the runtime probe added here spawns a real `docker version` subprocess, and this file mocks command-exists but not child_process, the probe runs for real. On macOS the sandbox-exec branch returns before probing, so it passed there and on CI runners that have docker; on any other host without a running daemon getSandboxCommand throws and all four tests fail on image assertions they never reach. Mock the docker/podman `version` probe to report healthy, so selection is deterministic and the tests exercise image precedence on every platform. Every other spawnSync call stays real. Reported by @qwen-code /review on #7734. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): cache the sandbox probe and sanitize its error output loadSandboxConfig runs twice on a sandboxed startup, so every candidate was probed twice — the wedged-docker-then-podman fallback paid the 5s cap twice (~10s), which the PR description wrongly called "once per wedged runtime". Cache each command's probe outcome per process (with a test-only reset), mirroring the ripgrep health cache, so a runtime is contacted at most once. The probe also returned the runtime's stderr verbatim into FatalSandboxError messages, carrying ANSI/control bytes to the terminal. Strip them with the existing stripAnsiAndControl helper, whose own doc names this case. Both requested by @wenshao in the review on #7734 (items 1 and 3). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): keep an all-control-character probe failure from reading as usable The sanitizer checked the failure line for emptiness before stripping, so a runtime whose stderr is only escape/control bytes stripped to '' — falsy — and the broken runtime was selected as usable, reintroducing the presence-vs- liveness bug through the sanitizer. Check emptiness after stripping and fall back to the synthesized message. Also drop the redundant `candidate !== 'sandbox-exec'` guard (sandbox-exec is only a candidate once its presence is confirmed), reword the all-broken hint to "try another installed runtime" since another may be installed but also broken, and add tests pinning the control-character failure and the first-of-several- broken diagnosis. Reported by @qwen-code /review on #7734. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| acp-bridge | ||
| audio-capture | ||
| channels | ||
| chrome-extension | ||
| cli | ||
| core | ||
| cua-driver | ||
| desktop | ||
| desktop-shell | ||
| mobile-mcp | ||
| sdk-java | ||
| sdk-python | ||
| sdk-typescript | ||
| vscode-ide-companion | ||
| web-shell | ||
| web-templates | ||
| webui | ||
| zed-extension | ||