[Bug]: Local message sends fail during history restore when an inactive SSH workspace shares the same path

Start with coordinator.rs around lines 6415-6440, then trace session_store_port.rs and legacy_compat.rs to follow workspace identity and path-only resolution during history restore. Add regression coverage for new and restored local sessions alongside remote sessions and managed worktrees, preserving the diagnostic for ambiguous path-only resolution; done means a same-path inactive remote record no longer blocks the owning local session.

Summary

A local session cannot send messages when an inactive SSH workspace record has the same absolute root path. Both an existing session and a newly created Standard session fail before a model request is made:

Session error: InvalidRequest: Session workspace_path does not resolve to a local workspace or a registered remote workspace: /Users/example/Project/home

The local directory exists and the session already has an explicit local workspace ID and execution target. Expected: history restoration should resolve the owning workspace by its ID, so a separately registered remote workspace with the same path does not prevent local conversations.

Area

Desktop app

Reproduction or evidence

1. Register a local project such as /Users/example/Project/home.
2. Register an SSH workspace whose root has the same path string.
3. Leave the SSH workspace inactive. Its persisted record still exists even if it is absent from the open/recent lists.
4. Select the local project and create a new Standard session.
5. Send a short message, or retry a message in an existing session whose context must be restored.
6. The send fails with the error above. Creating another session or switching models does not resolve it.

Observed workspace records, with identifying values replaced:

[
  {
    "id": "local_example",
    "rootPath": "/Users/example/Project/home",
    "workspaceKind": "normal",
    "metadata": { "sshHost": "localhost" }
  },
  {
    "id": "remote_example",
    "rootPath": "/Users/example/Project/home",
    "workspaceKind": "remote",
    "status": "Inactive",
    "metadata": {
      "connectionId": "[email protected]",
      "sshHost": "remote.example"
    }
  }
]

The newly created session carries the correct identity:

{
  "workspaceId": "local_example",
  "projectWorkspaceId": "local_example",
  "workspacePath": "/Users/example/Project/home",
  "projectWorkspacePath": "/Users/example/Project/home",
  "workspaceHostname": "localhost",
  "executionTarget": {
    "kind": "local",
    "rootPath": "/Users/example/Project/home"
  }
}

Backend logs stop after context is empty, restoring from persistence and Starting session history restore. The Web UI then reports manage_dialog_queue failure with the error above. No model request is made for the failed send.

Recovery was verified on the affected install: after backing up the registry and removing only the inactive same-path SSH record while the app was stopped, the local record was the sole candidate after restart. The formerly failing new local session then accepted the greeting and completed a normal user/assistant turn in about 5.5 seconds. Existing local and remote session directories were retained. The restarted host also required clearing the stale local queue reminder and restoring the undelivered draft (queue_scope_expired) before a fresh submission could proceed.

Source-level cause

Inspected the source at the installed build commit, 39b27f5a8a65324c6cd9ca7dae614990f91791e5:

• coordinator.rs, lines 6415-6440 calls resolve_session_restore_path with the path and optional SSH metadata, discarding the session's workspaceId / projectWorkspaceId.
• session_store_port.rs, lines 16-35 constructs a new SessionConfig without either workspace ID, then calls normalize_session_workspace. Its .ok()? discards the underlying error.
• legacy_compat.rs, lines 52-73 finds both records for the path and returns Workspace path is ambiguous; select a workspace by its ID or saved SSH connection.

The resulting user-facing message incorrectly suggests that no workspace resolves, rather than reporting the discarded ambiguity.

Suggested fix: preserve the authoritative project/workspace ID through the history-restoration path and use resolve_workspace_storage when an ID is available. Keep path-only resolution at the legacy compatibility boundary and preserve its diagnostic error. Regression coverage should exercise a newly created local session and a restored local session with an inactive same-path remote registration, plus remote sessions and managed worktrees so history remains bound to the owning project.

Related but distinct: #2375 reported a same-path local/remote collision in rollback classification. This report concerns message submission and history restoration in 1.0.3.

Environment, if relevant

• OpenBitFun: stable desktop 1.0.3
• Installed build commit: 39b27f5a8a65324c6cd9ca7dae614990f91791e5
• OS: macOS 27.0.1 (26A434)
• Deployment: desktop on the local Mac, with a separately saved SSH workspace
• Agent: Standard
• Model/provider: failure occurs before model execution; reproduced with two model selections
• Workaround: back up the workspace registry, quit the app, remove only the unused same-path SSH workspace record, and restart. Closing the workspace or removing it from recent lists does not remove the conflicting record. Project files and session history are retained.