--doctor: warn when bwrap mount dst shadows a default RO mount (/usr, /etc, /bin, /sbin, /lib*)

[sabiut]

Follow-up from PR #531 review.

Problem

The cowork bwrap sandbox uses a fixed set of default RO mounts (see scripts/cowork-vm-service.js:1299-1321):

• /usr, /etc (always)
• /bin, /lib, /lib64, /sbin (on non-merged-usr distros)

coworkBwrapMounts.additionalROBinds and additionalBinds allow user mounts. The forbidden set is {/, /proc, /dev, /sys} — none of the default RO mount points are in it. So both forms accept entries that target a default mount as their dst:

• Object form (feat(bwrap): support {src, dst} mount form in coworkBwrapMounts #531): { src: "/home/u/fake-etc", dst: "/etc" } passes validation.
• String form (pre-existing): "/etc" (RO only — RW would fail the not-under-$HOME rule, RO has no such constraint).

In mergeBwrapArgs, additional binds are appended to defaultArgs, so the user's --ro-bind … /etc is honored over the earlier default --ro-bind /etc /etc. The system view of /etc is silently replaced inside the sandbox — a non-obvious config footgun, not a sandbox escape.

Proposed fix

Add a doctor-side _warn in _doctor_check_bwrap_mounts (scripts/doctor.sh), parallel to the existing disabledDefaultBinds critical-mount warning. Sketch from @RayCharlizard's PR #531 review:

# scripts/doctor.sh — after the rw_binds rendering loop (~line 272)
local dst_warned=false
for line in $ro_binds $rw_binds; do
    [[ $line == *' -> '* ]] || continue
    local dst=${line##* -> }
    case $dst in
        /usr|/usr/*|/etc|/etc/*|/bin|/bin/*|/sbin|/sbin/*|/lib|/lib/*|/lib64|/lib64/*)
            _warn "Mount dst '${dst}' shadows a default sandbox mount" \
                  '(may break system tools inside the sandbox)'
            dst_warned=true
            ;;
    esac
done

Note: Travis's sketch only catches the object form (the -> separator). The string form "/etc" is rendered as just /etc by the fmt() helper in PR #531 — the same case-statement needs to apply to bare paths too. Will fold both into the implementation.

Acceptance

• _doctor_check_bwrap_mounts warns when an additional RO/RW bind's dst is /usr, /etc, /bin, /sbin, /lib, /lib64, or any subpath thereof.
• Triggers for both string form ("/etc") and object form ({src:'/x', dst:'/etc'}).
• No false positives on /tmp, /run, $HOME/..., or /sandbox/....
• BATS coverage in tests/cowork-bwrap-config.bats for each shadow case + a clean case.
• One-line note in docs/CONFIGURATION.md (Issue 2 from feat(bwrap): support {src, dst} mount form in coworkBwrapMounts #531 review).

---

Written by Claude Opus 4.7 via Claude Code

[github-actions]

Automated draft — AI analysis, not maintainer judgment. This bot won't approve enhancements, prioritize roadmap, or commit timelines. The notes below flag existing surfaces and design questions that may be worth considering before implementation.

Looks like the ask is to extend _doctor_check_bwrap_mounts with a _warn that fires when any additional bind's destination shadows a default sandbox RO mount (/usr, /etc, /bin, /sbin, /lib*), covering both the string and object config forms.

Existing surfaces worth knowing about:

• The disabledDefaultBinds case-statement warn loop appears to be the structural parallel the new shadow-dst _warn calls would mirror — same while IFS= read -r loop, same case shape, same _warn/critical_warned pattern. (scripts/doctor.sh:246-269)
• The ro_binds and rw_binds rendering loops likely mark the insertion point for the new shadow-dst check — the bind_path variable produced here carries the candidate dst value the new case statement would inspect. (scripts/doctor.sh:232-244)
• The defaultBwrapArgs construction appears to be the authoritative list of default sandbox mount paths (/usr, /etc, /bin, /lib, /lib64, /sbin) — the new doctor case pattern would need to mirror this set to stay in sync. (scripts/cowork-vm-service.js:1271-1290)

Design-review questions:

• When this feature fails for a user, what do they see in --doctor output or ~/.cache/claude-desktop-debian/launcher.log? Silent failure is the default without explicit logging.
• What's the smallest test that would catch a regression of this feature? Pointing at an existing test file or a BATS case that the new code would be added alongside keeps review concrete.
• Does this change the shape of existing user-facing behavior (flags, paths, environment variables, default state)? If yes, is there a deprecation path for users on the prior behavior?

Full investigation artifacts attached to the triage workflow run.