You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i installe dopencode a couple of days ago, used it and worked fine. TOday i want to continue, but it is not starting anymore.
Just nothing, no error, no crash report, nothing
It would also help to know your terminal (PowerShell, CMD, Windows Terminal, etc.) and the exact opencode version (opencode --version or the npm package version), as well as whether you're running the desktop app or the CLI version. This can help narrow down which existing issue this relates to.
When a desktop app suddenly stops starting on Windows after previously working, I would check version-selection and persisted state boundaries before assuming the provider itself broke.
A small startup receipt usually helps: selected app version, selected provider config, state-directory path, and the first failing bootstrap stage. Otherwise these regressions all collapse into "won't start" even when the real defect is a stale state or wrong-version launch path.
guys same issue i faced i tried installing and uninstalling multiple times times it shows they made for 16-bit system but ours are not so it dosn't run even i tried with npm and bun later i downgraded to v1.15.0 its worked then it made a auto update so again the same issue then i changed the config and all set up now i use v1.15.0
If the real symptom is just "double-click exe, nothing happens," then the next split should be as low-friction as possible:
Did the process start and crash, or never start at all?
Open Task Manager, double-click OpenCode.exe, and see whether a process appears briefly.
Did Windows log an application error?
Event Viewer -> Windows Logs -> Application
look for an Error entry around the exact launch time with OpenCode.exe or a DLL/runtime name
Can the binary say anything from a terminal?
open cmd.exe
run the installed exe from its folder, or run opencode --version if the CLI is on PATH
That gives maintainers a very different direction depending on the result:
process never appears -> launcher / packaging boundary
process flashes then dies with an Application Error -> native crash / dependency boundary
terminal prints an error -> bootstrap/config boundary
The reason I am pushing that split is the downgrade anecdote above: that sounds more like a startup-path regression than a user config problem, and the fastest way to prove that is one event-log entry or one terminal error line.
The startup report probably needs one operator-readable boundary receipt before deeper logging: terminal launch path, shell/process split, event-log presence, and the first failure bucket. That gives Windows users something actionable without making them read framework internals.
I have tested and this may be a temporary fix if you are on Windows.
In my condition, I have npm config (.npmrc) setting ignore-scripts to true and I realise it will throw an error message saying it is not compatible once opening.
I have tried disable the ignore-scripts flag to install the 1.15.X version and it work fine now, no more incompatible error.
And I guess the ignore-scripts block opencode from execute essential thing and make it crash.
What I did: Disable ignore-scripts -> install / update -> reenable ignore-scripts
And it didn't complain anymore. Force it not auto update required tho or else it just update itself and hit the same thing again.
If that is reproducible, this looks less like a generic "Windows can't run it" problem and more like an install-time/bootstrap dependency not being prepared before first launch. In other words: packaging/startup path, not user error.
The next useful maintainer proof would be very small:
fresh install with ignore-scripts=true
fresh install with ignore-scripts=false
compare first-launch behavior and the first terminal/event-log error in each case
If those diverge consistently, the installer probably needs an explicit preflight or a clearer hard-fail message before the GUI no-op path.
Would be curious to hear whether that A/B check reproduces cleanly for others, because that would narrow this issue a lot.
Activity
sander816 commentedon May 20, 2026
reinstalled, deleted various folers, no luck
github-actions commentedon May 20, 2026
This issue might be a duplicate of existing issues. Please check:
It would also help to know your terminal (PowerShell, CMD, Windows Terminal, etc.) and the exact opencode version (
opencode --versionor the npm package version), as well as whether you're running the desktop app or the CLI version. This can help narrow down which existing issue this relates to.Keesan12 commentedon May 20, 2026
When a desktop app suddenly stops starting on Windows after previously working, I would check version-selection and persisted state boundaries before assuming the provider itself broke.
A small startup receipt usually helps: selected app version, selected provider config, state-directory path, and the first failing bootstrap stage. Otherwise these regressions all collapse into "won't start" even when the real defect is a stale state or wrong-version launch path.
sander816 commentedon May 20, 2026
i have no idea whaty you are talking about
i just double click on OpenCode.exe and nothing happens
sulaimanh7877 commentedon May 21, 2026
guys same issue i faced i tried installing and uninstalling multiple times times it shows they made for 16-bit system but ours are not so it dosn't run even i tried with npm and bun later i downgraded to v1.15.0 its worked then it made a auto update so again the same issue then i changed the config and all set up now i use v1.15.0
Keesan12 commentedon May 21, 2026
If the real symptom is just "double-click exe, nothing happens," then the next split should be as low-friction as possible:
OpenCode.exe, and see whether a process appears briefly.OpenCode.exeor a DLL/runtime namecmd.exeopencode --versionif the CLI is on PATHThat gives maintainers a very different direction depending on the result:
The reason I am pushing that split is the downgrade anecdote above: that sounds more like a startup-path regression than a user config problem, and the fastest way to prove that is one event-log entry or one terminal error line.
Keesan12 commentedon May 22, 2026
The startup report probably needs one operator-readable boundary receipt before deeper logging: terminal launch path, shell/process split, event-log presence, and the first failure bucket. That gives Windows users something actionable without making them read framework internals.
PineappleBrain commentedon May 23, 2026
Hi everyone,
I have tested and this may be a temporary fix if you are on Windows.
In my condition, I have npm config (.npmrc) setting ignore-scripts to true and I realise it will throw an error message saying it is not compatible once opening.
I have tried disable the ignore-scripts flag to install the 1.15.X version and it work fine now, no more incompatible error.
And I guess the ignore-scripts block opencode from execute essential thing and make it crash.
What I did: Disable ignore-scripts -> install / update -> reenable ignore-scripts
And it didn't complain anymore. Force it not auto update required tho or else it just update itself and hit the same thing again.
Keesan12 commentedon May 25, 2026
That
ignore-scriptsworkaround is a strong clue.If that is reproducible, this looks less like a generic "Windows can't run it" problem and more like an install-time/bootstrap dependency not being prepared before first launch. In other words: packaging/startup path, not user error.
The next useful maintainer proof would be very small:
ignore-scripts=trueignore-scripts=falseIf those diverge consistently, the installer probably needs an explicit preflight or a clearer hard-fail message before the GUI no-op path.
Would be curious to hear whether that A/B check reproduces cleanly for others, because that would narrow this issue a lot.
sander816 commentedon Jun 1, 2026
tried again, and now i am getting this when i try to run in in cmd:
`PS C:\Users\sander\AppData\Local\Programs\opencode-aidesktop> .\OpenCode.exe --version
PS C:\Users\sander\AppData\Local\Programs\opencode-aidesktop>
15:54:14.418 (crash) > crash reporter started {
path: 'C:\Users\sander\AppData\Roaming\ai.opencode.desktop\Crashpad'
}
15:54:14.450 > app starting { version: '1.15.13', packaged: true, onboardingTest: false }
15:54:14.483 > tauri migration: already done, skipping
15:54:14.489 > auto updater configured {
channel: 'latest',
allowPrerelease: false,
allowDowngrade: true,
currentVersion: '1.15.13'
}
[34432:0601/155414.498:ERROR:content\browser\gpu\gpu_process_host.cc:996] GPU process exited unexpectedly: exit_code=-2147483645
15:54:14.498 (utility) > child process gone {
details: {
type: 'GPU',
reason: 'crashed',
exitCode: -2147483645,
serviceName: 'GPU'
}
}
15:54:14.515 (network) > net log started {
path: 'C:\Users\sander\AppData\Roaming\ai.opencode.desktop\logs\20260601T135414\network.netlog'
}
15:54:14.529 > sidecar connection started { url: 'http://127.0.0.1:64194' }
15:54:14.530 > spawning sidecar { url: 'http://127.0.0.1:64194' }
[34432:0601/155414.532:ERROR:content\browser\gpu\gpu_process_host.cc:996] GPU process exited unexpectedly: exit_code=-2147483645
15:54:14.532 (utility) > child process gone {
details: {
type: 'GPU',
reason: 'crashed',
exitCode: -2147483645,
serviceName: 'GPU'
}
}
[34432:0601/155414.554:ERROR:content\browser\gpu\gpu_process_host.cc:996] GPU process exited unexpectedly: exit_code=-2147483645
15:54:14.555 (utility) > child process gone {
details: {
type: 'GPU',
reason: 'crashed',
exitCode: -2147483645,
serviceName: 'GPU'
}
}
[34432:0601/155414.574:ERROR:content\browser\gpu\gpu_process_host.cc:996] GPU process exited unexpectedly: exit_code=-2147483645
15:54:14.574 (utility) > child process gone {
details: {
type: 'GPU',
reason: 'crashed',
exitCode: -2147483645,
serviceName: 'GPU'
}
}
[34432:0601/155414.593:ERROR:content\browser\gpu\gpu_process_host.cc:996] GPU process exited unexpectedly: exit_code=-2147483645
15:54:14.592 (utility) > child process gone {
details: {
type: 'GPU',
reason: 'crashed',
exitCode: -2147483645,
serviceName: 'GPU'
}
}
[34432:0601/155414.613:ERROR:content\browser\gpu\gpu_process_host.cc:996] GPU process exited unexpectedly: exit_code=-2147483645
[34432:0601/155414.613:FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:417] GPU process isn't usable. Goodbye.
`
github-actions commentedon Aug 1, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.