TypeError: Failed to fetch #27474

Activity

1. github-actions

   assigned

   Hona

   on May 14, 2026
2. github-actions commented on May 14, 2026

   

   github-actionsBot

   on May 14, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Bug]: Renderer crashes with TypeError: Failed to fetch in fetchMessages when background subagent completes #27292: Same TypeError: Failed to fetch in fetchMessages/loadMessages renderer stack trace when a background subagent completes — Windows 11, same version range
   • Renderer crashes with TypeError: Failed to fetch when multiple background agents complete simultaneously #27440: Same renderer crash with identical stack trace triggered by background agents completing simultaneously (also Windows 11)

   If your issue is the same, please add a reaction or comment on one of those issues so it can be tracked there.
3. QFinn-Penguin commented on May 14, 2026

   

   QFinn-Penguin

   on May 14, 2026

   Author

   More actions

   此问题可能与现有问题重复。请检查：

   • [Bug]：后台子代理完成时，渲染器崩溃并出现 TypeError: Failed to fetch in fetchMessages  #27292：后台子代理完成时，渲染器堆栈跟踪中也出现相同错误 — Windows 11，版本范围TypeError: Failed to fetch相同fetchMessages``loadMessages
   • 渲染器崩溃并出现 TypeError：当多个后台代理同时完成时获取失败 #27440：相同的渲染器崩溃，堆栈跟踪相同，由后台代理同时完成触发（也是 Windows 11）。

   如果您遇到的问题相同，请在这些问题下方添加点赞或评论，以便我们跟踪您的问题。

   确实是相同的问题，希望能尽快解决，实在是很影响使用，一下子就崩溃了
4. masterleelee commented on May 15, 2026

   

   masterleelee

   on May 15, 2026

   More actions

   我也是，新开的opencode就可以对话一次，第二次就报错。failed to fetch。我让他卸载ohmyopencode 重新打开就可以正常对话了。
5. QFinn-Penguin commented on May 18, 2026

   

   QFinn-Penguin

   on May 18, 2026

   Author

   More actions

   我也是，新开的opencode就可以对话一次，第二次就报错。failed to fetch。我让他卸载ohmyopencode 重新打开就可以正常对话了。

   好像不要点进去看子agent就没事
6. lrq3000 commented on Jun 23, 2026

   

   lrq3000

   on Jun 23, 2026

   More actions

   For me it was not oh-my-openagent / oh-my-opencode as I uninstalled it months ago, the Failed to fetch error happened after sending one prompt (just "Please continue") and after a few minutes of running.

   I found out it was caused by the tools output being way too verbose and somehow overloading OpenCode core and making it crash, hence why it fails to fetch.

   Here is how my agent analyzed the issue postmortem (after I fixed it by instructing it to work around the issue instead of retrying it constantly):

   ---

   Using systematic-debugging to explain the failure mode.

   What happened:

   • I tried to follow TDD strictly by forcing the focused unit tests to execute with --rerun-tasks.
   • The command was: ./gradlew :app:testDebugConfigDebugUnitTest --rerun-tasks --tests ...
   • In this repo, --rerun-tasks is very heavy because it invalidates Gradle task outputs and forces Android/Kotlin/KSP/resource/test tasks to rebuild rather than using the incremental cache.
   • That produced a long, noisy Gradle run with a lot of output and work. In OpenCode, that appears to have overloaded or wedged the message/tool-output pipeline, causing the “fails to fetch messages” / non-responsive behavior you saw.
   • The hang was not caused by the code change itself. It was caused by repeatedly invoking the forced Gradle rerun command inside the OpenCode harness.

   How I avoided it after you warned me:

   • I stopped using --rerun-tasks immediately.
   • I switched back to normal Gradle commands:
     • ./gradlew :app:testDebugConfigDebugUnitTest --tests ...
     • ./gradlew testDebugConfigDebugUnitTest
     • ./gradlew assembleDebugConfigDebug
   • I accepted that the focused command could be reported as UP-TO-DATE, then relied on the normal full unit test task, which did execute :app:testDebugConfigDebugUnitTest once and completed successfully.
   • I also used git diff --check and diff review for lightweight validation without triggering heavy rebuild behavior.

   The practical lesson:

   • In this OpenCode environment, avoid --rerun-tasks for Android/Gradle unless explicitly necessary.
   • If we need a fresh focused test run later, a safer approach is to make a real source/test change that naturally invalidates the right task, or run the normal full test command without forcing the entire task graph.

   --

   Can you generalize the lesson? What was the core issue that needs to be avoided in the future? It seems to me that it is about avoiding overloading or wedging the message/tool-output pipeline in OpenCode with long noisy outputs?

   --

   Yes. The generalized lesson is:

   Avoid commands that can overwhelm OpenCode’s tool-output/message pipeline through long-running, noisy, or forced-rebuild behavior, especially when the same result can be obtained incrementally or with narrower verification.

   Core issue:

   • The problem was not Gradle itself, nor tests themselves.
   • The issue was repeatedly running a command pattern that produced excessive work plus excessive output inside an interactive agent harness.
   • --rerun-tasks invalidated Gradle’s incremental behavior, causing broad recompilation/resource/KSP/test work and large logs.
   • OpenCode then appeared to wedge while transporting or rendering the tool output/messages.

   Future rule:

   • Prefer incremental, bounded, low-output commands.
   • Avoid “force everything” flags such as --rerun-tasks, clean, broad rebuilds, verbose/debug logs, or full test suites unless necessary.
   • If a heavy command is necessary, run it once, with a high timeout, and avoid repeating it after interruptions.
   • Treat repeated interrupted long-output commands as a harness-risk signal, not just a build/test issue.

   Practical guidance:

   • Use focused tests first, normal incremental mode.
   • Use full tests/builds only when needed for final verification.
   • Avoid --info, --debug, --stacktrace, --scan, --rerun-tasks, and clean build unless diagnosing a specific failure.
   • Do not force fresh execution just to satisfy process purity if the harness becomes unstable.
   • If Gradle says UP-TO-DATE, use another lightweight evidence source where appropriate: source diff, test report timestamps, normal full test run, or a small targeted code/test change that naturally invalidates the task.
   • If output starts becoming huge or the tool is interrupted, stop escalating. Switch to quieter commands or ask before continuing.

   A good mental model:

   • OpenCode is not a raw terminal. It is a terminal plus message transport plus renderer.
   • The safe unit is not only “will the command finish,” but also “can the harness reliably capture and present the output.”
   • Commands that are acceptable in a local terminal can be bad in an agent harness if they flood the output channel.
7. masterleelee commented on Jun 23, 2026

   

   masterleelee

   on Jun 23, 2026 via email

   More actions

     您好，您的邮件已经收到了
8. shijunti19 commented on Jul 4, 2026

   

   shijunti19

   on Jul 4, 2026

   More actions

   Has it been fixed? It’s completely unusable.
9. 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.
10. MikiraSora commented on Aug 20, 2026

    

    MikiraSora

    on Aug 20, 2026

    More actions

    
11. masterleelee commented on Aug 20, 2026

    

    masterleelee

    on Aug 20, 2026 via email

    More actions

      您好，您的邮件已经收到了
12. 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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
13. thdxr

    closed this as not plannedon Oct 11, 2026
14. masterleelee commented on Oct 11, 2026

    

    masterleelee

    on Oct 11, 2026 via email

    More actions

      您好，您的邮件已经收到了
15. lrq3000 commented on Oct 11, 2026

    

    lrq3000

    on Oct 11, 2026

    More actions

    For those who are still having this issue, it's because you are using Opencode V1 or Opencode Desktop, which which necessarily uses open code v1 core and the problem is that it uh crashes when uh the the nested path is too long and and which happens very very frequently with agents uh when they when they work in work trees or when they make builds uh etc so uh because of the temporarily uh temporarily intermediate files that are generated so you should uh there is a workaround here it is :

            ```
            $env:OPENCODE_EXPERIMENTAL_DISABLE_FILEWATCHER = "1" & "$env:LOCALAPPDATA\Programs\@opencode-aidesktop\OpenCode.exe"
            ```
    

    This disables the uh uh filewatcher and it's unnecessary for any uh operation. It's just for uh convenience to to see what files were modified exactly and to walk into the file tree directly from the Open Code interface. but if you just want to uh code with open code you don't need that the agents still have access to the whole uh set of functionalities and the whole file system.