Skip to content

Windows Desktop: 'Open in PowerShell' fails (directory passed as script argument) #42563

Closed

Description

@jshames-doc

Describe the bug

In OpenCode Desktop on Windows, the session header Open in menu's PowerShell entry fails. Picking it spawns powershell.exe with the project directory passed as a script-file argument, so PowerShell exits immediately with CommandNotFoundException (exit code 1). The app shows a "Request failed" error toast (from the open-path IPC rejection), and a PowerShell window briefly flashes with the script error.

This is distinct from the earlier spawn [object Promise] ENOENT bug (#26928/#27078), which is already fixed in current versions — resolveAppPath() is now correctly awaited. This is a remaining functional bug in how the resolved app path is invoked for PowerShell on Windows.

Reproduction steps

  1. Open OpenCode Desktop on Windows (tested on 1.18.18).
  2. Open a project (e.g. one whose path contains spaces).
  3. In the session header, open the Open in dropdown and select PowerShell.
  4. Observe the error.

Expected behavior

Selecting PowerShell should open a working PowerShell session rooted at the current project directory (like the working terminal paths do).

Actual behavior

powershell.exe is launched with the directory as a positional argument, which PowerShell interprets as a script file path. Result: CommandNotFoundException, exit code 1, and a "Request failed" toast. The exact main-process call is effectively:

execFile("C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", ["C:\\path\\to\\project"])

Error from PowerShell:

The term 'C:\path\to\project' is not recognized as the name of a cmdlet, function, script file, or operable program. ... CommandNotFoundException

File Explorer (shell.openPath) works, and View → Toggle Terminal / session terminal (PTY path) work — only the Open in → PowerShell path is broken.

Suggested fix

On Windows, don't pass the directory as a positional script argument. Use the child's working directory instead, e.g.:

execFile(pwsh.exe, ["-NoExit"], { cwd: projectDir })

or, for Windows PowerShell (the current where powershell resolution), something like:

execFile(powershell.exe, ["-NoExit", "-Command", `Set-Location -LiteralPath '${projectDir}'`], { windowsHide: false })

Environment

Activity

  1. github-actions commented on Aug 14, 2026

    @github-actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    These issues describe the same root cause: the project directory being passed as a positional argument to PowerShell instead of being used as the working directory.

  2. jshames-doc commented on Aug 14, 2026

    @jshames-doc
    Author

    This is a duplicate of #39851 (and #40277), which describe the exact same root cause: the Windows 'Open in PowerShell' flow passes the project directory as a positional argument to powershell.exe, causing CommandNotFoundException. Closing in favor of #39851.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions