feature(desktop): system tray icon with clean shutdown of the background opencode-cli service (Windows) #50633

Activity

1. github-actions

   assigned

   Hona

   on Sep 22, 2026
2. github-actions commented on Sep 22, 2026

   

   github-actionsBot

   on Sep 22, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Desktop: option to minimize to tray / keep running when window is closed #42349: Desktop: option to minimize to tray / keep running when window is closed — same request for a system tray icon on Windows Desktop, with the same underlying issue of the background opencode-cli service outliving the app window
3. VcDoc commented on Sep 24, 2026

   

   VcDoc

   on Sep 24, 2026

   More actions

   Seeing this on macOS 27.0 with Desktop 2.0.15 too: the desktop process is gone, but its CLI service remains and the Dock shows “Running in Background”.

   I understand #39286 intentionally preserves the shared service. Would you accept an explicit Quit and stop local service menu action on v2? It would leave normal Quit unchanged and ask for confirmation that stopping the local service can interrupt other clients and running work. This addresses the shutdown part of this issue without adding the tray behavior discussed in #42349.

   I'd be happy to contribute a focused PR if this scope fits and nobody is already implementing it.
4. kusesad-1122 commented on Oct 9, 2026

   

   kusesad-1122

   on Oct 9, 2026

   More actions

   Reproduced on Desktop 2.0.26 / Windows 11 23H2: no tray icon is registered at all (checked the full corner-overflow flyout + after Explorer restart), so there is no in-UI path to quit the lingering service. Details in #54217.
5. Muguett-DBY commented on Oct 24, 2026

   

   Muguett-DBY

   on Oct 24, 2026

   Sponsor

   More actions

   Adding a Windows Desktop-only use case on OpenCode Desktop 2.1.4 (bundled CLI also reports opencode v2.1.4).

   Environment: Windows 11 Insider Preview 26H2, build 26340.9767, x64, approximately 32 GB RAM.

   I use the Desktop app and do not intentionally run the CLI as a separate workflow. After closing the Desktop window:

   • No OpenCode.exe desktop processes were present, but opencode-cli.exe serve --service was still running.
   • The remaining process used approximately 476 MiB of private working-set memory and approximately 0.9 GiB of private committed memory. Its working set stayed around 476 MiB across seven samples over roughly one minute; this observation does not establish a memory leak.
   • Windows Task Manager displayed this process as Bun. Its executable was the Desktop-bundled opencode-cli.exe; its file metadata identified Bun 1.4.4, making it difficult to recognize that it belonged to OpenCode.
   • After rebooting Windows, before opening OpenCode again, neither the Desktop process nor this background process was running.

   I understand that preserving the shared v2 daemon after Desktop quits is intentional, as described in #39286. For someone who only uses the Desktop app, however, closing it while several hundred MiB remain allocated is surprising.

   I would appreciate an explicit Quit and stop local service action in the Desktop UI, with a warning if stopping the shared service could interrupt other clients or running work. A Restart background service action would also make troubleshooting easier without requiring a terminal or Task Manager.

   This feedback concerns discoverability and control of the background service lifecycle; I have not reproduced the stale-configuration behavior described in the original report.
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the detailed write-up, @villa-feng!

   To restate the request: you'd like OpenCode Desktop on Windows to have a system tray icon. Its menu would have a Quit OpenCode item that also cleanly stops the background opencode-cli service, and optionally show the service's status/PID and offer a Restart background service item. The simpler alternative would be a button in the Desktop UI that does the same. Maintainers will consider it.

   Some context: Desktop deliberately runs OpenCode as a shared background service (opencode serve --service) that keeps running after the window closes, and it reuses an already-running service when it starts again. So the lingering process is expected. What's missing is a way to manage it from the UI.

   Until then, you can use the CLI instead of Task Manager or Stop-Process:

   opencode service status   # show the running background service
   opencode service restart  # stop it and start a fresh one
   opencode service stop     # stop it

   One more thing: v2 is meant to watch your global config (~/.config/opencode/opencode.json) and reload changes, including disabled_providers, without a restart. If you can reliably reproduce an edit there not taking effect while the service is running, please open a separate bug with the steps. That would be a bug in its own right, apart from this feature request.
7. VariableVince commented on Oct 28, 2026

   

   VariableVince

   on Oct 28, 2026

   Last edited by VariableVince

   More actions

   Additional evidence on 2.2.0 desktop / Windows 11 (10.0.26300) that this is still current, and that it also keeps MCP servers alive:

   • Quit the app → opencode-cli.exe serve --service (PID 28384, ~394 MB, listening on 127.0.0.1:28894) stays running; its parent PID is already gone.
   • 3× Serena MCP python.exe remain as children of that orphaned service (started 18:37:49, 18:37:50, 18:40:02) — so "MCP processes don't close" is a downstream symptom here (there are seperate issues open for this already BUT not specifically about the python.exe instances, more about the MCP servers themselves being orphaned if i understand correctly).
   • App log after relaunch: v2 CLI background service ready { probed: true, port: '28894' }, i.e. the leftover is reused, no clean restart (which seems deliberate according to the comment above). No stopping/stopped entry anywhere on quit.
   • opencode service get returns {} — there is no idle-timeout / stop-on-quit setting to opt into.

   Suggestion: treat "quit desktop → stop the service it spawned (graceful, then terminate) and reap its MCP children" as the required behavior, with the tray Quit service control as the discoverable surface. If persistence is intentional for the shared service (as per comment above), the quit flow should say so and the next launch should restart it cleanly rather than reuse a process from a previous app instance.

   Current behaviour is just very weird if this is intended: i only use Opencode Desktop v2, not the OpenCode CLI version. Why leave a process running at all? Should be opt-in (setting) rather than by default imo. Now i have to kill a process manually each time? Not to mention all those users who don't know of this and ask themselves why 300-400MB+ memory is still used after closing the program? Let alone the still running python.exe's accumulating to almost 700MB memory. Again just weird.
8. Maolin-home commented on Oct 29, 2026

   

   Maolin-home

   on Oct 29, 2026

   More actions

   Also hitting this on Windows 11 (Desktop 2.2.0, OS build 26300, x64).

   Confirming that there is no tray icon at all — this is not a rendering or promotion bug:

   • HKCU\Control Panel\NotifyIconSettings has no entry for OpenCode.exe, while other Electron apps on the same machine (Edge, VS Code-family, Clash Verge, …) do have entries. The app never registers a tray icon.
   • The shipped desktop bundle (resources/app.asar) contains no tray implementation.
   • The classic task-list entry exists and paints correctly, so the window itself is healthy — the tray area simply has nothing to show.

   Impact in daily use:

   • The window is the only entry point, so clicking x kills the UI (open tabs, unsent drafts, in-flight runs) while opencode-cli serve --service keeps running in the background.
   • There is no way to tell "is OpenCode running / does it need me" without hunting for the window.
   • Because the UI is gone but the service lingers, the next launch can end up talking to a service holding stale config — the exact situation described above.

   Current workaround: a ~7 KB WinForms tray shim (own exe, startup shortcut) that locates the main window and calls ShowWindow(SW_HIDE / SW_RESTORE) + SetForegroundWindow, with a context menu for show / hide-to-tray / quit. It covers the window lifecycle, but it cannot manage the opencode-cli service or the session state behind it — which is exactly what an in-app tray should own.

   Feature ask (aligns with #58035 and PR #52365):

   1. Tray icon on Windows with: show/focus window, close-to-tray (keep the UI alive), and a real Quit that stops the app and shuts down opencode-cli serve --service cleanly.
   2. Opt-in setting for the close button behaviour (quit vs. minimize to tray), so users who want the process to end keep that default.
   3. Ideally a status dot on the icon when a session needs permission or input.

   Happy to test a Windows build of #52365 if that PR is still the plan.

   Environment

   • opencode version: 2.2.0 (OpenCode Desktop, release channel)
   • OS: Windows 11 Home 26H2, 10.0.26300 (win32 x64)
   • Shell: PowerShell 5.1 / cmd.exe
   • Install/channel: %LOCALAPPDATA%\Programs\ai.opencode.desktop
   • Active plugins: none

   👍React with 👍1Reacted by sensor
9. sweethzx commented on Nov 1, 2026

   

   sweethzx

   on Nov 1, 2026

   Last edited by sweethzx

   More actions

   OpenCode - Encerrar serviço.txt

   Uma alternativa é utilizar um script BAT para automatizar a inicialização e a limpeza desses processos.

   Como funciona?

   O script executa três operações principais:

   1. Encerra processos antigos do opencode-cli.exe.
   2. Inicia o OpenCode Desktop.
   3. Monitora o aplicativo e encerra processos residuais do CLI quando o Desktop é fechado.

   Como utilizar?

   1. Abra o Bloco de Notas.
   2. Copie o código disponibilizado.
   3. Salve o arquivo como Reiniciar-OpenCode.bat.
   4. Execute o arquivo para iniciar o OpenCode.

   Observação: o caminho do executavel precisa corresponder ao local onde o OpenCode está instalado no computador.

   Essa solução automatiza a limpeza dos processos do CLI durante a abertura e o encerramento do aplicativo, podendo contornar conflitos causados por processos residuais.

   👍React with 👍1Reacted by Sweeth
10. HopeItBuilds commented on Nov 3, 2026

    

    HopeItBuilds

    on Nov 3, 2026

    More actions

    I can confirm this still affects OpenCode Desktop 2.2.5 on Windows. After closing the Desktop window, the bundled opencode-cli.exe serve process remains running.
11. olobarius commented on Nov 7, 2026

    

    olobarius

    on Nov 7, 2026

    More actions

    +1 for the explicit menu item @VcDoc suggested, as a smaller step than a tray icon. Still the case on Desktop 2.2.6 / Windows 11.

    Concrete proposal: File → Quit OpenCode Completely, right after Close Window. It asks first ("Running sessions on every connected device are interrupted, including browser tabs, phones and the terminal"; Cancel is the default), then runs the existing service stop with the staged CLI and quits. Normal Quit and closing the window keep the service running, as #39286 intends.

    It already works as a small local GUI plugin (main only, one MenubarItem, about 60 lines), so nothing in the service needs to change. Happy to turn it into a PR in packages/desktop if a maintainer wants it.