Repository navigation
Description
Summary
On Windows, opening the same folder with different drive/path letter casing creates two distinct loaded Locations (e.g. C:\dev\XRTemplate vs canonical C:\Dev\XRTemplate). Sessions created in the non-canonical-cased location consistently fail to start with Instruction initialization blocked by unavailable sources: core/instructions, while the canonical-cased location works.
Environment
- opencode version: v0.0.0-beta-19242
- OS: Microsoft Windows NT 10.0.26200.0 (Get-ComputerInfo: Windows 10 Pro, WindowsVersion 2009)
- Terminal: TERM=xterm-256color; TERM_PROGRAM/COLORTERM empty (original failure seen as a "Session failed" popup in the OpenCode client; reproduced headless via
opencode2 api) - Shell: ComSpec=C:\Windows\system32\cmd.exe (repro commands run via PowerShell)
- Install/channel: beta
- Active plugins:
C:\Dev\opencode-fff-v2(configured identically in both~/.config/opencode/opencode.jsonand~/.config/opencode/opencode.jsonc)
Reproduction
- On Windows, have a project whose on-disk canonical path is
C:\Dev\XRTemplate(dir C:\showsDev;git rev-parse --show-toplevelreturnsC:/Dev/XRTemplate;/api/projectcanonical isC:\Dev\XRTemplate). - Create a session with the non-canonical casing:
opencode2 api post /api/session --data '{"location":{"directory":"C:\\dev\\XRTemplate"}}' - Send a message:
opencode2 api post /api/session/<lowercase-session-id>/prompt --data '{"text":"ping"}' - Observe the session drain fail with
Instructions.InitializationBlocked. - Repeat steps 2-3 with canonical
C:\\Dev\\XRTemplate: instruction init succeeds and the run proceeds to the provider step (in my test it then failed only with a provider billing error, proving instructions loaded).
Expected Behavior
On a case-insensitive filesystem, C:\dev\XRTemplate and C:\Dev\XRTemplate should resolve to the same Location/project. Instruction discovery (AGENTS.md) should succeed regardless of the input casing.
Actual Behavior
Two separate locations stay loaded:
[{"directory":"C:\\dev\\XRTemplate"},{"directory":"C:\\Users\\small"},{"directory":"C:\\Dev\\XRTemplate"},{"directory":"C:\\dev"}]The lowercase session fails on prompt with:
Instructions.InitializationBlocked: Instruction initialization blocked by unavailable sources: core/instructions
at jE (B:/~BUN/root/chunk-w3nvgx7v.js:30:66822)
at <anonymous> (B:/~BUN/root/chunk-w3nvgx7v.js:32:2899)
at InstructionState.observe (B:/~BUN/root/chunk-w3nvgx7v.js:32:1283)
...
at SessionRunner.drain (B:/~BUN/root/chunk-kva4f2k6.js:24:2279)
GET /api/session/<lowercase-id>/message returns {"data":[]} (blocked before any assistant step), while the uppercase session returns a normal assistant message. The client shows a "Session failed / Instruction initialization blocked by unavailable sources: core/instructions" popup.
Additional Context
- Frequency: consistent. Reproduced on demand 2026-09-07 on beta-19242. Historic
/api/sessionlist shows the same pattern: everylocation: C:\dev\XRTemplate(orc:\Dev\XRTemplate) session hasoutcome: failedwith zero tokens, whileC:\Dev\XRTemplatesessions succeed. - Server log (
~/.local/share/opencode/log/opencode.log,role=server) shows watcher subscribes/startsC:\Dev\XRTemplate\AGENTS.mdfor the canonical location, but no correspondingC:\dev\XRTemplate\AGENTS.mdsubscribe for the lowercase location — only globalAGENTS.mdentries. Lowercase boot still runsgit rev-parsefromC:\dev\XRTemplatebut the subsequentremote get-urlcwd flips to canonicalC:\Dev\XRTemplate, suggesting the mismatch between Location string and git/project canonical path breaks discovery. - Project listing confirms canonical:
{"id":"2790c750067519a6185802abf291df9f47e482cc","canonical":"C:\\Dev\\XRTemplate","vcs":"git"}. A separate lowercase parent projectC:\devexists and works, so the breakage specifically hits the non-canonical project-subpath location. - Config contents are valid (
/api/configmerges globalopencode.json/opencode.jsoncplus projectopencode.jsonwithmetavr/meta-xr-operatorMCP and the fff plugin; only benign normalization warnings for legacyprovider.qwen...reasoningandexperimental.disable_paste_summary). Secrets redacted — not pasted. - Workaround:
opencode2 service restart, then only openC:\Dev\XRTemplate(canonical case). Avoidcd C:\dev\XRTemplate/ lowercase recents. - Test sessions created during diagnosis were deleted afterwards.
Activity
asineth0 commentedon Sep 13, 2026
thanks i just wasted a half hour with this issue
JJLiebig commentedon Sep 15, 2026
Confirmed this still reproduces consistently with
@opencode/cli@2.0.3on Windows 11 Pro, build 26200.C:\code\herdrgit rev-parse --show-toplevel:C:/Code/herdrInstructions.InitializationBlocked: ... unavailable sources: core/instructionsC:\Code\...continued working concurrently through the same background service.opencode debug configlaunched from the lowercase path already reports the project agent directory asC:\Code\herdr\.agents, showing mixed canonical/non-canonical paths before instruction initialization.cwd="C:\code\herdr"and subsequently runsgit remote get-url originwithcwd="C:\Code\herdr", matching the casing transition described in this issue.This suggests the bug remains present in the current stable
2.0.3release and is location-specific rather than a generally unhealthy background service.mariopasquali commentedon Sep 28, 2026
Guys, already got hit by this 4 times, would be awesome to have a fix
neriousy commentedon Oct 20, 2026
Fixed by #53349, released in v2.0.24. Instruction loading now handles project roots whose casing differs on Windows (e.g.
C:\dev\repovsC:\Dev\repo), so those sessions no longer fail withInitializationBlocked: core/instructions. If you still see this on v2.0.24 or later, comment and we'll reopen.