Cairn
NousResearch/hermes-agent

Docker/remote backend receives host paths instead of container paths

Cluster 39143 · environments. Data as of

2 open items. Fix attempted, not merged.

The short answer

0open issues
2open PRs
9items grouped
Known?
Yes. 9 related items grouped here, 4 issues already closed.
Fix event
No fix has been merged to main. 3 PRs closed without merging; see the attempts below.
Tracker
The maintainers' tracker marks this unresolved. That is separate from the fix event.
Still open
0 issues and 2 PRs.

Multiple bugs and proposed fixes around host-side paths (Windows drive letters, symlinks, macOS paths) incorrectly reaching Docker or SSH remote backends as working directories or file tool arguments. Members cover detection, sanitization, and path-preservation approaches across Windows, macOS, and WSL2 environments.

Open issues0

No open issues.

Open PRs2

  • PR#49753fix(terminal): detect all Windows drive letters in host paths (#49703)
  • PR#60977fix(docker): sanitize non-C Windows drive cwd

3 PRs closed without merging

From the close comments: duplicate 1 · superseded by another PR 1 · other 1

  • #48157 fix(docker): normalize Windows drive-letter paths for `-w` flag (#48137) · duplicate → #48168
  • #48168 fix(docker): prevent Windows drive-letter paths reaching ``docker run -w`` · other
  • #61053 fix(docker): reject Windows drive cwd overrides · superseded by another PR → #60977
Closed issues · 4
  • Closed#39143Windows: Docker backend fails with 'invalid working directory' on Docker Desktop WSL2; Desktop App also fails with
  • Closed#48137[Windows] Docker terminal backend: -w gets raw Windows path (exit 125), and docker_mount_cwd_to_workspace exposes entire home dir
  • Closed#49703Docker backend fails on Windows: host path injected as container working directory
  • Closed#60962docker terminal backend: _HOST_CWD_PREFIXES only recognizes C:\, other Windows drive letters leak to `docker run -w` (exit 125)
How this cluster was grouped
  • Link evidence (partly structural links): some members are connected by structural evidence (shared changed files, or a closing/superseded reference); the rest are joined by an automated relevance judgement over their text.
  • Members outside that structural core may belong to a different underlying problem.
  • Pairwise link density 0.18: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36. 1.00 means every pair is linked.

Pick up a Lab task

Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.

Open the Lab

At a glance

Subsystem
environments
Closed issues
4
Attempts
3 PRs closed without merging

For your agent

The same facts, typed.

cluster/39143.json
cluster/39143.md