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.json and ~/.config/opencode/opencode.jsonc)
Reproduction
- On Windows, have a project whose on-disk canonical path is
C:\Dev\XRTemplate (dir C:\ shows Dev; git rev-parse --show-toplevel returns C:/Dev/XRTemplate; /api/project canonical is C:\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/session list shows the same pattern: every location: C:\dev\XRTemplate (or c:\Dev\XRTemplate) session has outcome: failed with zero tokens, while C:\Dev\XRTemplate sessions succeed.
- Server log (
~/.local/share/opencode/log/opencode.log, role=server) shows watcher subscribes/starts C:\Dev\XRTemplate\AGENTS.md for the canonical location, but no corresponding C:\dev\XRTemplate\AGENTS.md subscribe for the lowercase location — only global AGENTS.md entries. Lowercase boot still runs git rev-parse from C:\dev\XRTemplate but the subsequent remote get-url cwd flips to canonical C:\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 project C:\dev exists and works, so the breakage specifically hits the non-canonical project-subpath location.
- Config contents are valid (
/api/config merges global opencode.json/opencode.jsonc plus project opencode.json with metavr/meta-xr-operator MCP and the fff plugin; only benign normalization warnings for legacy provider.qwen...reasoning and experimental.disable_paste_summary). Secrets redacted — not pasted.
- Workaround:
opencode2 service restart, then only open C:\Dev\XRTemplate (canonical case). Avoid cd C:\dev\XRTemplate / lowercase recents.
- Test sessions created during diagnosis were deleted afterwards.
Summary
On Windows, opening the same folder with different drive/path letter casing creates two distinct loaded Locations (e.g.
C:\dev\XRTemplatevs canonicalC:\Dev\XRTemplate). Sessions created in the non-canonical-cased location consistently fail to start withInstruction initialization blocked by unavailable sources: core/instructions, while the canonical-cased location works.Environment
opencode2 api)C:\Dev\opencode-fff-v2(configured identically in both~/.config/opencode/opencode.jsonand~/.config/opencode/opencode.jsonc)Reproduction
C:\Dev\XRTemplate(dir C:\showsDev;git rev-parse --show-toplevelreturnsC:/Dev/XRTemplate;/api/projectcanonical isC:\Dev\XRTemplate).opencode2 api post /api/session --data '{"location":{"directory":"C:\\dev\\XRTemplate"}}'opencode2 api post /api/session/<lowercase-session-id>/prompt --data '{"text":"ping"}'Instructions.InitializationBlocked.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\XRTemplateandC:\Dev\XRTemplateshould 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:
GET /api/session/<lowercase-id>/messagereturns{"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
/api/sessionlist shows the same pattern: everylocation: C:\dev\XRTemplate(orc:\Dev\XRTemplate) session hasoutcome: failedwith zero tokens, whileC:\Dev\XRTemplatesessions succeed.~/.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.{"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./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.opencode2 service restart, then only openC:\Dev\XRTemplate(canonical case). Avoidcd C:\dev\XRTemplate/ lowercase recents.