Windows Companion try to resolve paths on the local machine for remote agent Workspace

[danilovmy]

Summary

When Windows Companion is connected to a remote agent/gateway, the Advanced -> Agents -> main -> Workspace view does not show the expected files because it appears to resolve/browse paths against the local Windows machine instead of the remote agent workspace.

Why this matters

The whole point of the remote Workspace view is to inspect the remote agent's workspace/files. If the UI tries to interpret those paths locally, the file rail/browser becomes misleading or empty for legitimate remote paths.

Repro

1. Connect Windows Companion to a remote agent/gateway.
2. Open Advanced -> Agents -> main -> Workspace.
3. Expect to browse the remote agent workspace/files.
4. Observe that the view does not show the expected files and behaves as if the paths are being resolved on the local Windows machine.

Expected

• Workspace browsing should be scoped to the connected remote agent/gateway.
• File listing and preview should use the remote workspace APIs and remote path semantics.
• Remote absolute paths should never be treated as local Windows filesystem paths just because the UI is running on Windows.

Actual

• The Workspace tab does not show the expected remote files.
• Behavior suggests local path resolution / local-machine assumptions rather than remote workspace-backed browsing.

Notes / suspected shape

This looks related to the existing Workspace/file-rail work:

• #876 Add Workspace session file rail
• #871 Follow up Workspace file rail parity gaps
• #956 Fix workspace file previews

Especially #956 looks adjacent because it explicitly mentions routing the Workspace page through:

• agents.workspace.list
• agents.workspace.get

with fallback behavior for older gateways.

So this may be:

1. a regression in the remote-workspace path,
2. an incomplete remote-agent case not covered by the earlier fix,
3. or a fallback path still using local/path-based assumptions when remote agents.workspace.* should be authoritative.

Suggested fix

• Ensure the Workspace page uses remote agents.workspace.list/get results as canonical when connected to a remote agent/gateway.
• Do not reinterpret remote paths as local Windows paths in the UI layer.
• Audit fallback order so older-gateway fallbacks still preserve remote scope instead of accidentally dropping into local-machine browsing semantics.
• Add an explicit regression test for a remote/non-Windows-style workspace root.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 11, 2026, 4:09 PM ET / 20:09 UTC.

Summary
Keep this issue open: current main still limits the Workspace page to session-scoped files and the legacy managed-file fallback, so it does not reliably provide the reported agent-wide remote workspace view.

Reproducibility: no. not yet at high confidence from a live current-main setup. Source inspection does establish that the page lacks an agent-wide workspace transport and can only show session-scoped or legacy managed files, which is consistent with the reported result.

Root-cause cluster
Relationship: canonical
Canonical: #969
Summary: This issue is the active canonical report for remote agent-wide Workspace browsing; the related open issue has a narrower parity scope and the closest candidate PR closed unmerged.

Members:

• adjacent_distinct: Follow up Workspace file rail parity gaps #871 - It tracks artifact rows, refresh/collapse affordances, and visual parity rather than remote workspace scope.
• partial_overlap: Add Workspace session file rail #876 - It introduced the current session-scoped file rail and compatibility fallback architecture implicated by this report.
• fixed_by_candidate: Fix workspace file previews #956 - It proposed agent-wide workspace routing, but it closed unmerged and lacked live proof against a gateway supporting those methods.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
The defect is bounded to the Workspace gateway transport and projection, with clear likely files and a focused validation path.

Review details

Best possible solution:

Add a verified typed agent-workspace list/get transport ahead of the session and managed-file fallbacks, preserve remote paths as opaque protocol identifiers, and prove a non-Windows remote root through tests and a current-head WinUI run.

Do we have a high-confidence way to reproduce the issue?

No, not yet at high confidence from a live current-main setup. Source inspection does establish that the page lacks an agent-wide workspace transport and can only show session-scoped or legacy managed files, which is consistent with the reported result.

Is this the best way to solve the issue?

Yes, with one refinement: use a typed and verified agent-workspace gateway contract before the existing compatibility fallbacks rather than adding any local filesystem special case.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The agents.workspace contract is absent from the checked-in protocol snapshot, so a fix must verify the actual gateway request and response contract instead of copying the closed PR's raw requests blindly.
• A live current-main reproduction against a remote gateway supporting agent-wide workspace methods was not available during this read-only review.
• The local file history is partly collapsed into the v0.6.12 baseline commit, limiting precise attribution for the original implementation.

Codex review notes: model internal, reasoning high; reviewed against 622c0e27c6b0.

Label changes

Label changes:

• add P2: The issue is a bounded but meaningful defect in remote Workspace inspection rather than a core connectivity failure.
• add impact:ux-friction: The intended remote file view is empty or incomplete, making the Workspace UI misleading and increasing operator support burden.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: The issue is a bounded but meaningful defect in remote Workspace inspection rather than a core connectivity failure.
• impact:ux-friction: The intended remote file view is empty or incomplete, making the Workspace UI misleading and increasing operator support burden.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• Launch ./run-app-local.ps1 -Isolated, connect to a remote gateway with a non-Windows workspace root, and capture listing, navigation, and preview proof

What I checked:

• Current transport boundary: WorkspacePage calls sessions.files.list and falls directly back to agents.files.list when unsupported; there is no agent-wide workspace API tier. (src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml.cs:138, 622c0e27c6b0)
• No literal local filesystem access: The affected page and projection model contain no System.IO Path, File, or Directory calls; the observable problem is more likely incomplete gateway transport or protocol-path projection than direct local disk browsing. (src/OpenClaw.Tray.WinUI/Pages/WorkspaceFilesModel.cs:318, 622c0e27c6b0)
• Existing remote-path invariant: Current projection tests explicitly require a gateway request path to remain verbatim, confirming that remote paths should be treated as protocol identifiers rather than resolved on Windows. (tests/OpenClaw.Tray.Tests/WorkspaceFilesModelTests.cs:77, 622c0e27c6b0)
• Prior implementation candidate: Commit def36aa adds agents.workspace.list/get routing and full-workspace projection tests, but it belongs to a closed-unmerged PR and is not an ancestor of current main. (src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml.cs, def36aa995d7)
• Feature provenance: The current Workspace file-rail behavior traces to the v0.6.12 baseline, while the more recent agent-wide workspace implementation was explored in the closed candidate commit. (src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml.cs:92, 4166e0fd63f8)
• Repository remained clean: All review inspection was read-only and the checkout remained unchanged at the supplied main SHA. (622c0e27c6b0)

Likely related people:

• bkudiess: Authored the merged Workspace file rail and the closest agent-wide workspace candidate implementation. (role: feature owner; confidence: high; commits: 556e7dafc4ba, def36aa995d7; files: src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml.cs, src/OpenClaw.Tray.WinUI/Pages/WorkspaceFilesModel.cs, tests/OpenClaw.Tray.Tests/WorkspaceFilesModelTests.cs)
• Scott Hanselman: The current Workspace page and model history resolve to the v0.6.12 baseline commit under this author, providing secondary routing context where earlier granular history is unavailable. (role: baseline importer and adjacent owner; confidence: low; commits: 4166e0fd63f8; files: src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml.cs, src/OpenClaw.Tray.WinUI/Pages/WorkspaceFilesModel.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[clawsweeper]

🦞⚠️
Automatic implementation stopped before completion.
Reason: The automatic implementation worker stopped before all deterministic gates completed. Open the workflow run for the exact blocker.
Worker: https://github.com/openclaw/clawsweeper/actions/runs/29173264896