open remote vscode windows with --new-window - #3155
Conversation
…g the current one. closes generalaction#2904
Greptile SummaryThis PR changes local and remote VS Code-family launches to request a fresh editor window.
Confidence Score: 3/5The PR is not yet safe to merge because remote new-window launching remains broken for supported VS Code Insiders-only installations. The preferred remote path always invokes Files Needing Attention: apps/emdash-desktop/src/main/host/remoteOpenIn.ts, apps/emdash-desktop/src/main/host/remoteOpenIn.test.ts, apps/emdash-desktop/src/core/primitives/open-in-apps/api/open-in-apps.test.ts
|
| Filename | Overview |
|---|---|
| apps/emdash-desktop/src/main/core/app/service.ts | Adds preferred remote editor CLI execution with explicit new-window arguments and URL fallback. |
| apps/emdash-desktop/src/main/host/remoteOpenIn.ts | Adds shared remote folder URI and executable mapping helpers, but maps supported VS Code Insiders installations to the stable-only executable. |
| apps/emdash-desktop/src/core/primitives/open-in-apps/api/open-in-apps.ts | Adds new-window flags to local launch commands for three VS Code-family editors on supported platforms. |
| apps/emdash-desktop/src/main/host/remoteOpenIn.test.ts | Tests the VS Code mapping and URI serialization but not editor variants or service-level launch behavior. |
| apps/emdash-desktop/src/core/primitives/open-in-apps/api/open-in-apps.test.ts | Adds one macOS VS Code assertion while leaving most changed platform/editor commands uncovered. |
Sequence Diagram
sequenceDiagram
participant U as User
participant A as AppService
participant C as Editor CLI
participant E as Editor URL handler
U->>A: Open remote workspace
A->>C: --new-window --folder-uri URI
alt CLI succeeds
C-->>U: New remote editor window
else CLI unavailable or fails
A->>E: Open vscode-family URL
E-->>U: Editor-defined window reuse behavior
end
Prompt To Fix All With AI
### Issue 1
apps/emdash-desktop/src/main/host/remoteOpenIn.ts:66
**Insiders Uses Wrong CLI**
The `vscode` app is considered installed when either `code-insiders` or the VS Code Insiders bundle is present, but this function always selects `code`. On an Insiders-only installation, the preferred CLI launch fails and falls back to the existing `vscode://` URL, which can reuse the current window and leaves the remote multi-workspace bug unfixed for a supported installation.
### Issue 2
apps/emdash-desktop/src/main/host/remoteOpenIn.test.ts:49-55
**Launch Paths Lack Coverage**
These tests cover only the VS Code CLI mapping and one shared folder URI. They do not exercise the service-level CLI invocation and fallback or the Cursor and VSCodium mappings. Likewise, `open-in-apps.test.ts:115` checks only one macOS VS Code command even though this PR changes three editors across three platforms. As a result, the tests would miss mistakes such as selecting the wrong executable or omitting a new-window flag from most changed configurations.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "open remote vscode-family editors in a n..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| export function buildRemoteEditorCli(scheme: Exclude<RemoteEditorScheme, 'zed'>): string { | ||
| if (scheme === 'vscodium') return 'codium'; | ||
| if (scheme === 'cursor') return 'cursor'; | ||
| return 'code'; |
There was a problem hiding this comment.
The vscode app is considered installed when either code-insiders or the VS Code Insiders bundle is present, but this function always selects code. On an Insiders-only installation, the preferred CLI launch fails and falls back to the existing vscode:// URL, which can reuse the current window and leaves the remote multi-workspace bug unfixed for a supported installation.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/emdash-desktop/src/main/host/remoteOpenIn.ts
Line: 66
Comment:
**Insiders Uses Wrong CLI**
The `vscode` app is considered installed when either `code-insiders` or the VS Code Insiders bundle is present, but this function always selects `code`. On an Insiders-only installation, the preferred CLI launch fails and falls back to the existing `vscode://` URL, which can reuse the current window and leaves the remote multi-workspace bug unfixed for a supported installation.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.| describe('buildRemoteEditorFolderUri', () => { | ||
| it('builds a vscode-remote folder uri for a new window', () => { | ||
| expect(buildRemoteEditorCli('vscode')).toBe('code'); | ||
| expect(buildRemoteEditorFolderUri('localhost', 'dev', '/repo')).toBe( | ||
| 'vscode-remote://ssh-remote+7b22686f73744e616d65223a226c6f63616c686f7374222c2275736572223a22646576227d/repo' | ||
| ); | ||
| }); |
There was a problem hiding this comment.
These tests cover only the VS Code CLI mapping and one shared folder URI. They do not exercise the service-level CLI invocation and fallback or the Cursor and VSCodium mappings. Likewise, open-in-apps.test.ts:115 checks only one macOS VS Code command even though this PR changes three editors across three platforms. As a result, the tests would miss mistakes such as selecting the wrong executable or omitting a new-window flag from most changed configurations.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/emdash-desktop/src/main/host/remoteOpenIn.test.ts
Line: 49-55
Comment:
**Launch Paths Lack Coverage**
These tests cover only the VS Code CLI mapping and one shared folder URI. They do not exercise the service-level CLI invocation and fallback or the Cursor and VSCodium mappings. Likewise, `open-in-apps.test.ts:115` checks only one macOS VS Code command even though this PR changes three editors across three platforms. As a result, the tests would miss mistakes such as selecting the wrong executable or omitting a new-window flag from most changed configurations.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
1 participant
summary
opening a second remote workspace used
vscode://which reuses the existing window. the cli now preferscode --new-window --folder-uri vscode-remote://...(and cursor/codium equivalents), with the url as fallback.local vscode/cursor/codium launch commands also pass
-n/--new-window.closes #2904
test plan
pnpm --dir apps/emdash-desktop exec vitest run --project node src/main/host/remoteOpenIn.test.ts src/core/primitives/open-in-apps/api/open-in-apps.test.ts