Remote backend: adding workspaces uses local filesystem and rejects remote paths

[caseyjkey]

Summary

When Backend mode = Remote, adding a workspace from the desktop client still validates paths against the client filesystem instead of the remote daemon filesystem.

This makes it impossible to add workspaces in common server/client setups such as:

• Windows UI -> WSL remote daemon
• macOS UI -> remote Linux daemon

The UI shows errors like:

Added 0 workspaces. Skipped 1 invalid path (not a folder).

Expected behavior

When using a remote backend, adding a workspace should be remote-aware:

• either browse/select paths from the remote machine's filesystem, or
• accept/normalize remote path formats such as WSL paths and forward them to the daemon for validation.

Actual behavior

The desktop client opens the local folder picker and validates against the local machine.

That means:

• Windows client can browse into WSL from Explorer and select a folder, but the selected WSL/Linux server folder is still rejected by the UI as invalid in remote mode
• macOS client cannot add Linux server folders from the UI
• even when the remote daemon connection is healthy, workspace creation fails with invalid path (not a folder)

Reproduction

Windows -> WSL remote daemon

1. Run CodexMonitor daemon in WSL/Linux.
2. Connect CodexMonitor on Windows with Backend mode = Remote.
3. Try to add a workspace that exists on the WSL/Linux side, including one selected through Explorer under \\wsl\## Summary When Backend mode = Remote`, adding a workspace from the desktop client still validates paths against the client filesystem instead of the remote daemon filesystem.

This makes it impossible to add workspaces in common server/client setups such as:

• Windows UI -> WSL remote daemon
• macOS UI -> remote Linux daemon

The UI shows errors like:

Added 0 workspaces. Skipped 1 invalid path (not a folder).

Expected behavior

When using a remote backend, adding a workspace should be remote-aware:

• either browse/select paths from the remote machine's filesystem, or
• accept/normalize remote path formats such as WSL paths and forward them to the daemon for validation.

Actual behavior

The desktop client opens the local folder picker and validates against the local machine.

That means:

• Windows client can browse into WSL from Explorer and select a folder, but the selected WSL/Linux server folder is still rejected by the UI as invalid in remote mode
• macOS client cannot add Linux server folders from the UI
• even when the remote daemon connection is healthy, workspace creation fails with invalid path (not a folder)

Reproduction

Windows -> WSL remote daemon

1. Run CodexMonitor daemon in WSL/Linux.
2. Connect CodexMonitor on Windows with Backend mode = Remote.
   or \\wsl\.localhost.
3. Observe:
   • Windows can browse into WSL folders via Explorer
   • the selected WSL folder is still rejected by the UI in remote mode
   • error similar to Added 0 workspaces. Skipped 1 invalid path (not a folder).

macOS -> Linux remote daemon

1. Run CodexMonitor daemon on a Linux machine.
2. Connect CodexMonitor on macOS with Backend mode = Remote.
3. Try to add a workspace from the desktop UI.
4. Observe that the local macOS picker is used and remote Linux paths cannot be added.

Prior context

This remote behavior was introduced in #54, but multiple users are still hitting this exact workspace-add problem and no clear workaround has been provided.

Relevant reports in #54 comments include:

• WSL/Windows users reporting path errors and inability to add workspaces from the UI
• macOS user reporting that remote mode still opens the local macOS folder picker

Why this matters

Remote backend mode is working enough to connect and run against the server, but without a remote-aware workspace-add flow it is effectively incomplete for real WSL/Linux remote usage.

Possible solutions

1. Add a remote filesystem browser / remote folder picker when Backend mode = Remote.
2. Add explicit support for WSL and other remote path formats, and let the daemon validate them.
3. In remote mode, avoid client-side is this a local folder? checks and delegate validation to the daemon.
4. Provide a documented fallback/workaround if full remote browsing is not ready yet.

Temporary workaround

The only known workaround today is to add the workspace directly on the daemon side via remote API / CLI rather than through the desktop UI.

That is not discoverable and is not documented as an official workflow.