core: instruction initialization blocked by unavailable sources (Maximum call stack size exceeded) #50296

Activity

1. holny commented on Sep 21, 2026

   

   holny

   on Sep 21, 2026

   Contributor

   More actions

   Found the likely culprit — ancestorDirectories (packages/core/src/config/plugin/instruction.ts:133) recurses on dirname(start) and only terminates when start === stop. When the two paths don't string-match exactly (separator or case differences are easy to hit on Windows), the walk blows past stop, and since dirname("C:\\") keeps returning "C:\\" the recursion never bottoms out — hence the RangeError. That die is caught at :123, which marks the core/instructions source unavailable, so every session then fails with Instructions.InitializationBlocked — matching your trace exactly.

   Fix is to bound the walk at the filesystem root instead of relying on the string comparison reaching stop. PR shortly.

   🎉React with 🎉2Reacted by VimWei and Jack Stringer
2. VimWei commented on Sep 23, 2026

   

   VimWei

   on Sep 23, 2026

   Last edited by VimWei

   More actions

   The same issue, completely unusable.

   OpenCode v2.0.10 - 2.0.14 via npm
3. VimWei commented on Sep 23, 2026

   

   VimWei

   on Sep 23, 2026

   More actions

   1. OpenCode can be executed successfully in the following directories.
      C:\Apps
      C:\Users\chenw\Downloads\Documents
      C:\Apps\AOE
      C:\Apps\test\

   2. The following steps were executed, resulting in the previous error.
      C:\Apps\mdxpress
      c:\Apps\dachu-commit

   The analysis reveals a difference between these two scenarios: if previous sessions exist (e.g., opencode 1.x, but an upgrade to 2.x was performed during the initial run), an error occurs. If no previous sessions are present, the process runs normally.
4. VimWei commented on Sep 23, 2026

   

   VimWei

   on Sep 23, 2026

   More actions

   Narrowed down: triggered by legacy 1.x session data, not by version

   Not a duplicate — adding evidence to the existing diagnosis.

   Project dir	Has 1.x session?	Result
   C:\Apps	no	✅ works
   C:\Apps\AOE	no	✅ works
   C:\Apps\test	no	✅ works
   C:\Users<me>\Downloads\Documents	no	✅ works
   C:\Apps\mdxpress	yes	❌ InitializationBlocked
   C:\Apps\dachu-commit	yes	❌ InitializationBlocked

   • Version is NOT the variable: 2.0.10 and 2.0.14 both reproduce.
   • Directory location is NOT the variable: C:\Apps works, C:\Apps\test works.
   • 2.0.14 worked on very first run, before legacy sessions were loaded.
     Every new session after that fails.

   Hypothesis: one of start/stop in ancestorDirectories comes from the
   working-directory field migrated from 1.x sessions, and it doesn't
   string-match the current path (trailing slash / case / separator style).

   @holny — a root-filesystem guard alone is not enough. When start and stop
   are on different branches, the walk should return [] rather than the full
   ancestor chain, otherwise the crash becomes a wrong result.
5. holny commented on Sep 28, 2026

   

   holny

   on Sep 28, 2026

   Contributor

   More actions

   Gentle nudge — this has been open for a week with green checks and no review. The fix is small: ancestorDirectories walks iteratively with an explicit filesystem-root bound instead of recursing until two path strings compare equal, which overflows the stack on Windows when the forms drift. Covered by a dedicated regression test where stop is never an ancestor. Happy to rebase or adjust if anything needs changing.
6. Diambiru commented on Sep 29, 2026

   

   Diambiru

   on Sep 29, 2026

   More actions

   Additional confirmation from Windows 11 Home 10.0.26220: this still reproduces on OpenCode 2.0.16 and 2.0.19.

   • Both versions logged the same instruction-source activation failure:
     failed to activate instruction source
Cause([Die(RangeError: Maximum call stack size exceeded.)])
   • On 2.0.16, a subsequent session attempt failed with:
     Instructions.InitializationBlocked: Instruction initialization blocked by unavailable sources: core/instructions
     with InstructionState.observe -> InstructionState.prepare -> SessionRunner.prepareContext.
   • That failed 2.0.16 session recorded zero cost and zero input/output tokens.
   • On 2.0.19, the server was running opencode-cli.exe serve --service. During the diagnostic period, POST /api/location/reload completed successfully while the same RangeError was logged. No provider call was made during this 2.0.19 diagnostic.
   • The 2.0.19 check did not establish a subsequent Instructions.InitializationBlocked / session-preparation failure.
   • Read-only checks found no AGENTS.md at ~/.config/opencode, the checked home directory, the workspace root, or its checked parent directories.

   I have not isolated the triggering instruction source or confirmed that a case-variant location is the cause in this environment, so I am only reporting the observed symptom/version persistence here.

   This extends the confirmed affected-version range beyond 2.0.14 to at least 2.0.19.
7. rutexd commented on Sep 30, 2026

   

   rutexd

   on Sep 30, 2026

   More actions

   I'm having pretty same issue. v2.0.20. Its happening very random to me.

   The issue somehow appears randomly and sometimes resolved when im killed running server (kill opencode.exe)
   In some cases it looks to be depending on project (new session creating fine on empty projects and vice-versa: running fine on existing session and not creating on new projects)
   Sometimes the full package reinstall helps and sometimes not...
   I thought maybe it was a conflict with opencode v1 and tried to clean all caches and all configs which i could only find, but this doesn't looks to help much.

   Something is very strange happening here.
8. jack5github commented on Oct 1, 2026

   

   jack5github

   on Oct 1, 2026

   More actions

   Since updating to v2.0.21, this has begun to affect every single folder I attempt to use OpenCode in, making the program completely unusable.
9. neriousy

   closed this as completedon Oct 5, 2026