TypeError: Failed to fetch shortly after opening — unable to send any prompts #27755

Activity

1. github-actions commented on May 15, 2026

   

   github-actionsBot

   on May 15, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • TypeError: Failed to fetch #27474: Same "TypeError: Failed to fetch" error on Windows, occurring when the app is unable to reach the backend
   • filed to fetch Bug and freeze #27736: Similar "failed to fetch" error with app freezing on Windows

   If your issue is distinct from these, please add details clarifying what makes it different.
2. Echoice01 commented on May 15, 2026

   

   Echoice01

   on May 15, 2026

   Author

   More actions

   Hi, thanks for pointing these out. I've taken a look at both issues and they seem similar but not exactly the same as mine. Here's what makes mine different:

   Unlike the issues mentioned above where the app can still function to some extent, in my case, I can only send ONE message successfully after opening the app. The very next attempt immediately triggers the "Failed to fetch" error. After that, the app becomes completely unresponsive — no input or action works at all. Eventually the app throws a full error page.

   So the difference is that my app essentially breaks after just a single exchange, rather than intermittently failing or freezing during longer sessions. I'm not sure if this is related but I'm using the DeepSeek V4 Flash Free model via the Sisyphus provider.

   I'd appreciate any help or insights on this. Thank you!

   👍React with 👍1Reacted by Vedran Manojlovic
3. assranai commented on May 16, 2026

   

   assranai

   on May 16, 2026

   More actions

   same issue here TAT
4. assranai commented on May 16, 2026

   

   assranai

   on May 16, 2026

   More actions

   its said on Discord that issue may caused by plugins like omo v4.1.x . If so, reverting to v4.0 may can help
5. djeer commented on Jun 23, 2026

   

   djeer

   on Jun 23, 2026

   More actions

   Same problem on MacOS
6. wbdb commented on Jul 16, 2026

   

   wbdb

   on Jul 16, 2026

   Last edited by wbdb

   More actions

   TypeError: Failed to fetch
       at fetch (oc://renderer/assets/main-hem2imez.js:181474:45)
       at request (oc://renderer/assets/main-hem2imez.js:65797:24)
   

   No plugins installed.
7. Highjobop commented on Jul 30, 2026

   

   Highjobop

   on Jul 30, 2026

   More actions

   解决了吗，我也是这样
8. SusanWhiteUTK commented on Aug 27, 2026

   

   SusanWhiteUTK

   on Aug 27, 2026

   Last edited by SusanWhiteUTK

   More actions

   Same issue here Windows 11 pro 25H2, etc. Crashed between prompts, restart doesn't allow any connections or actions, just this error. Still debugging through help documents, but not getting very far. Hesitate to reinstall because I don't want to lose session history.

   Re-installing did nothing.

   The issue was OpenCode Desktop reading in a very long output file as a prompt or something like that (I didn't ask it to, it just did it). The heap (~768MB) was being blown up by the large file (suggested that the heap size was too small, by the way).

   I was able to continue troubleshooting using TUI in VSCode, which was still able to access the history and all the files etc. After it cleaned up after itself and removed that bogus data from wherever it had it stored, it came up clean. Not very specific, I know, but the method should be repeatable for others having similar issues.

   The output file was generated and located in the repo worktree, which seems to have been the source of the problem, as it recurred as soon as I accessed that session again with a new prompt in the GUI (TUI works fine). I had to move the file to a directory outside the worktree, go through the database cleanup again, and now everything is fine. Hope this helps.
9. spamail4 commented on Sep 4, 2026

   

   spamail4

   on Sep 4, 2026

   More actions

   Description

   OpenCode Desktop crashes its local backend (sidecar) a few minutes after any turn
   that actually edits files / does real tool work, on Windows. After the sidecar dies
   the UI can no longer reach it, so every subsequent "Send" fails with
   发送信息失败 / Failed to fetch until the app is fully restarted. The app does
   not auto-restart the sidecar.

   This was reproduced 6 times in a single session, with clean negative controls
   (trivial text-only replies, read-only explore turns and long idle periods do not
   crash). It is not caused by plugins (none installed), not by quota, not by
   session/data size, not by memory pressure (sidecar stays ~170–330 MB and never
   climbs), and it is not fixed by "snapshot": false.

   The crash signature matches the existing reports in #26667 / #27755 / #45409 —
   reproduced here on the latest version (1.18.27).

   Plugins

   No third-party plugins installed.

   OpenCode version

   OpenCode Desktop 1.18.27 (auto-update channel latest, says up-to-date).

   Steps to reproduce

   1. Launch OpenCode Desktop on Windows (renderer is served over the oc:// scheme;
      the engine runs in a Node utility sidecar on http://127.0.0.1:<random port>).
   2. Open a session and ask the agent to do a real task that writes/edits files
      (modify a source file, format several files, or spawn an explore subagent after
      an edit) in a normal code project.
   3. Let the turn finish (log shows exiting loop).
   4. Do nothing for ~2–5 minutes.
   5. Send the next message → it fails immediately with 发送信息失败 / Failed to fetch. Every further send fails too, until you fully close and relaunch the app.

   Note: the crash also occurred once while an explore subagent was still streaming
   steps (not only while idle after a finished turn). Trivial Q&A turns ("reply only",
   no tool calls) completed fine and did not crash even after 6+ minutes of idle.

   Screenshot and/or share link

   Error toast text: 发送信息失败 followed by Failed to fetch (renderer
   TypeError: Failed to fetch).

   Operating System

   Windows 10 Enterprise LTSC 2021 (build 10.0.19044). Also reported by others on
   Windows 11 (#26667/#27755/#45409).

   ---

   Evidence

   1. The sidecar crashes with a Windows fail-fast code, then the renderer loses it.

   <user AppData>\ai.opencode.desktop\logs\<run>\utility.log (identical on every crash):

   sidecar exited { code: 3221226505 }            # 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN / fail-fast)
   child process gone {
     details: {
       type: 'Utility',
       reason: 'crashed',
       exitCode: -1073740791,
       serviceName: 'node.mojom.NodeService',
       name: 'opencode server'
     }
   }
   

   ...\logs\<run>\renderer.log right after the crash, when the user hits Send:

   Uncaught (in promise) TypeError: Failed to fetch
   

   No spawning sidecar line appears again in main.log after the crash → the app
   does not restart it.

   2. Timing correlation (same machine, same day):

   Turn type	Ended (local)	Sidecar crash	Outcome
   Real multi-step editing turn	19:21:50	19:24:10	crashed (0xC0000409)
   Real editing turn	20:15:26	20:17:07	crashed (0xC0000409)
   Real editing + explore subagent (snapshot off)	21:50:10	21:53:28	crashed (0xC0000409)
   Fresh session, read-only explore + 2 follow-ups	20:35 / 20:42	–	no crash, 15+ min stable
   Trivial text-only reply in the SAME long session	20:59:09	–	no crash, 6+ min stable

   3. Engine log (<user data>/.local/share/opencode/log/opencode.log): each
   crashing turn ends with a normal exiting loop, and no ERROR/stream error/
   abort line is logged between the turn end and the crash. The crash itself produces
   no engine log line (native process death).

   4. Ruled out (with measurements):

   • Memory: sidecar working set sampled every 2 s stayed ~170–330 MB across
     crash/no-crash runs; no monotonic climb toward any heap limit.
   • Session/data size: total database is 151 MB; the largest session's stored
     content is only ~3.5 MB (1106 parts, biggest part 0.2 MB). Not a "bloated session".
   • "snapshot": false removes the tracking hash=... change-tracking lines but
     the crash still reproduces → not the snapshot/git subsystem.
   • Plugins: none. Quota/upstream: no provider error logged before the crash;
     it also crashed on turns with fully clean model streams. Provider/model:
     opencode-go / mimo-v2.5 (the built-in "Console Go" gateway — flaky at other
     times, but not the trigger here).
   • NODE_OPTIONS (--report-on-fatalerror) is rejected in packaged builds, and
     Crashpad leaves no local minidump, so only the 0xC0000409 exit code is observable.

   5. Suggested fix direction (consistent with #26667/#27755/#45409):
   The sidecar is killed by an unhandled error in session/turn teardown after
   tool-calling turns (session.processor family). Please make tool-turn completion
   crash-safe on Windows (catch AbortError / wrap the per-turn Effect fiber with an
   error boundary), and consider auto-restarting the sidecar when it dies so the UI
   does not hard-lock into Failed to fetch.

   Full diagnostics (memory time-series CSVs, engine/renderer/utility logs, a debug
   launcher) are available if a maintainer wants them.
10. Dante-dan commented on Oct 3, 2026

    

    Dante-dan

    on Oct 3, 2026

    Contributor

    More actions

    The 0xC0000409 exit is a Windows fail-fast termination, so an extra JS/Effect catch would not establish a fix. I checked v1.18.27 and current dev: SessionProcessor.process already handles interruption/AbortError and wraps processing with error handling and cleanup.

    One useful remaining isolation step is the native file watcher: Desktop enables it independently of snapshots, and snapshot: false does not disable its Windows binding. Could you fully quit Desktop, launch it with OPENCODE_EXPERIMENTAL_DISABLE_FILEWATCHER=true, and repeat the same editing turn and idle period? In PowerShell, set $env:OPENCODE_EXPERIMENTAL_DISABLE_FILEWATCHER='true' before launching the Desktop executable from that shell. Please confirm the new engine log has no watcher backend initialization line. This is a diagnostic A/B, not a confirmed workaround.

    If it still crashes, the most useful next evidence is the Windows Application Error entry's faulting module/version and exception details, plus the engine/utility log tails around that crash. Please redact personal paths. The exit code alone does not identify which native component failed; the related TUI AbortError reports do not establish the same cause.
11. thdxr commented on Oct 11, 2026

    

    thdxr

    on Oct 11, 2026

    Member

    More actions

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
12. thdxr

    closed this as not plannedon Oct 11, 2026