David Metcalfe 3d84689714 fix(computer_use): address sweeper feedback on --no-overlay subprocess + manifest probe ... The hermes-sweeper review #4701565902 (2026-07-15) flagged two consistency issues in `_cua_driver_supports_no_overlay` and one additive-config concern: 1. `cua-backend.py:260` — the `cua-driver --help` support probe inherited the full parent environment. cua-driver is a third-party binary; every other spawn site in this file (manifest probe at `:214`, MCP spawn at `:697`, install probe at `:997`) uses `_sanitize_subprocess_env(cua_driver_child_env())`. The `--help` probe should match. This was a low-impact leak (only help output exits), but inconsistency is the wrong default for a third-party subprocess. 2. `cua_backend.py:238` — when the manifest returned a `command` different from the input `driver_cmd` parameter (e.g. a relocated executable at `/opt/relocated/cua-driver` while the system binary is at `/usr/bin/cua-driver`), the support probe ran against `_CUA_DRIVER_CMD` (the default) instead of the manifest-discovered `command`. Two failure modes: - The wrapper binary supports `--no-overlay` but the system binary doesn't → probe returns False → overlay kept despite capability. - The system binary supports `--no-overlay` but the wrapper doesn't → probe returns True → MCP spawn crashes on the unknown flag. 3. The original commit bumped `_config_version` 31→32 for an additive default (`computer_use.no_overlay: None`). AGENTS.md specifies that additive defaults in existing sections are handled by deep merge and should NOT trigger a version bump. After cherry-picking onto current `origin/main` (which is already at 33), the bump is effectively dropped — resolved to main's 33. Changes: - Add `env=_sanitize_subprocess_env(cua_driver_child_env())` to the `--help` subprocess (with the same import + rationale comment as the manifest probe). - Pass `driver_cmd=command` (or `driver_cmd=driver_cmd` for the fallback path) into `_mcp_args_with_overlay_flag`, so the support probe runs against the binary that will actually be launched. Tests (3 new): - `test_help_probe_passes_sanitized_env` — verifies `subprocess.run` is called with an `env=` kwarg. - `test_manifest_command_drives_support_probe` — verifies the probe runs against the manifest command when it differs from the input driver_cmd. - `test_fallback_uses_input_driver_cmd_for_support_probe` — verifies the fallback path (no command in manifest) uses the input driver_cmd. - `test_probe_distinguishes_support_between_binaries` — sanity check that the lru_cache key on `driver_cmd` prevents cross-binary cache leakage. File-revert negative test confirmed all three of the new "manifest/probe" tests are load-bearing: with the pre-fix code, they fail (probe runs against the default binary instead of the resolved one); with the fix, they pass. 20/20 tests in `tests/computer_use/test_cua_no_overlay.py` green. `TestMcpInvocationResolution` (8/8) still green. Refs: sweeper review #4701565902		2026-07-23 00:44:43 -05:00
..
test_cua_cli_fallback_env.py	fix(computer-use): sanitize subprocess env in cua-driver CLI fallback transport	2026-07-05 13:57:20 -07:00
test_cua_no_overlay.py	fix(computer_use): address sweeper feedback on --no-overlay subprocess + manifest probe	2026-07-23 00:44:43 -05:00
test_cua_spawn_env_sanitization.py	fix(computer-use): sanitize env on the 4 remaining cua-driver spawn sites (#59165)	2026-07-05 14:48:20 -07:00
test_cua_telemetry.py	feat(computer_use): disable cua-driver telemetry by default, add opt-in (#50842)	2026-06-22 09:57:16 -07:00
test_doctor.py