Feature: support {src, dst} mount form in coworkBwrapMounts to allow distinct host/sandbox paths (e.g. persistent /tmp)

[cbonnissent]

Summary

coworkBwrapMounts (added in #339) lets users add bind mounts to the bwrap
sandbox but only as a string — which mergeBwrapArgs translates to
--bind <p> <p> (host path mounted at the same path inside the sandbox).

This means the host source and the sandbox destination are always identical,
which prevents a legitimate use case: replacing a default sandbox mount with a
persistent host directory mounted at the same in-sandbox path.

Motivating use case: persistent /tmp across Bash tool calls

Each Bash tool invocation in local-agent / Cowork mode spawns a fresh bwrap
process with --tmpfs /tmp (cowork-vm-service.js:1277) and
--die-with-parent (cowork-vm-service.js:1365). The tmpfs is destroyed when
the command exits, so anything written to /tmp is lost before the next call.

This breaks workflows that legitimately stage state in /tmp between commands:

• multi-step downloads (curl -o /tmp/... then process in a later call)
• pip install --user writing wheels to /tmp/... and reusing them
• tools that hardcode /tmp paths (get-pip.py, some installers)

Today there is no workaround:

• additionalBinds: [\"/tmp\"] would expose the host's /tmp to the sandbox
  (regression of the isolation the bwrap rewrite in fix: bwrap backend mounts at guest paths and uses minimal sandbox root #309 set up), and even then
  it requires disabledDefaultBinds: [\"/tmp\"] to remove the default tmpfs.
• There is no way to say "mount ~/.cache/claude-tmp from the host as
  /tmp inside the sandbox" — which is exactly what the user wants.

Proposal

Extend additionalROBinds and additionalBinds to also accept entries of the
form { \"src\": \"...\", \"dst\": \"...\" } in addition to the existing string form.

Example: persistent /tmp mapped to a host cache dir

{
  \"preferences\": {
    \"coworkBwrapMounts\": {
      \"additionalBinds\": [
        { \"src\": \"/home/user/.cache/claude-tmp\", \"dst\": \"/tmp\" }
      ],
      \"disabledDefaultBinds\": [\"/tmp\"]
    }
  }
}

Resulting bwrap args (excerpt):

... --proc /proc --tmpfs /run --bind /home/user/.cache/claude-tmp /tmp ...

Files written to /tmp inside the sandbox now survive across Bash calls,
without exposing the host /tmp.

Validation rules

• src: same checks as the current string form
  • absolute, not in FORBIDDEN_MOUNT_PATHS (/, /proc, /dev, /sys)
  • if RW (additionalBinds): must be under \$HOME
• dst: only the absolute + non-forbidden checks
  • the \$HOME constraint is intentionally skipped because the whole point
    of {src, dst} is to map onto sandbox paths outside \$HOME (/tmp,
    /sandbox/..., etc.)
• Malformed objects (missing src/dst, non-string values) are silently
  filtered out with a BwrapConfig: rejected ... warning, matching the
  existing string-validation behavior

Backwards compatibility

100%. The string form (\"/path\" → --bind /path /path) is preserved exactly
as-is. All 36 existing tests in tests/cowork-bwrap-config.bats pass without
modification.

Implementation status

I have a local patch that:

• Adds object-form support in loadBwrapMountsConfig.filterMounts
  (scripts/cowork-vm-service.js)
• Updates mergeBwrapArgs to emit --bind src dst per type
  (scripts/cowork-vm-service.js)
• Updates _doctor_check_bwrap_mounts to render the object form as
  src -> dst in --doctor output (scripts/doctor.sh, both Python and
  Node parser branches)
• Adds 13 new BATS tests covering accept/reject paths, mixed string+object
  configs, the persistent-/tmp recipe end-to-end, and the doctor
  rendering — all passing (58/58 total)

Tested end-to-end on a locally rebuilt .deb: the resulting bwrap command
line contains the expected --bind ~/.cache/claude-tmp /tmp and the
default --tmpfs /tmp is correctly stripped via disabledDefaultBinds.

Happy to open a PR if the design is acceptable.

References

• Feature: configurable bwrap mount points in claude_desktop_config.json #339 — original coworkBwrapMounts feature
• fix: bwrap backend mounts at guest paths and uses minimal sandbox root #309 — bwrap mount strategy rewrite (where --tmpfs /tmp was introduced)
• scripts/cowork-vm-service.js — loadBwrapMountsConfig / mergeBwrapArgs
  (lines 739–855)

---

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 coworkBwrapMounts array entries to accept { "src": "...", "dst": "..." } objects in addition to plain strings, so users can bind-mount a host path to a different in-sandbox destination (the motivating case being a persistent host directory mounted as /tmp).

Existing surfaces worth knowing about:

• The typeof p !== 'string' guard in filterPaths currently silently drops any non-string entry — this is the gate that would need to be widened to also accept and validate {src, dst} objects. (scripts/cowork-vm-service.js:766-776)
• The two emit loops in mergeBwrapArgs always pass the same variable p for both bwrap source and destination arguments — these are the sites that would need to emit distinct src/dst for object-form entries. (scripts/cowork-vm-service.js:847-852)
• The Python and Node inline scripts in _doctor_check_bwrap_mounts treat every entry as a plain string with print(p) / console.log(p) — both branches would need to handle the object form to render src -> dst correctly in --doctor output rather than emitting [object Object]. (scripts/doctor.sh:190-211)

Design-review questions:

• If this adds a new config key or changes an existing one, how is the schema versioned? Old configs should keep loading without error.
• Does this widen what the app reads, writes, or executes outside the sandbox? Any new file paths, network endpoints, IPC channels, or shelled-out commands should be named up front.
• 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.

Full investigation artifacts attached to the triage workflow run.