Skip to content

server: case-sensitive duplicate locations on Windows break instruction init (core/instructions) #47839

Closed

Description

@Angeloss

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

  1. 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).
  2. Create a session with the non-canonical casing:
    opencode2 api post /api/session --data '{"location":{"directory":"C:\\dev\\XRTemplate"}}'
  3. Send a message:
    opencode2 api post /api/session/<lowercase-session-id>/prompt --data '{"text":"ping"}'
  4. Observe the session drain fail with Instructions.InitializationBlocked.
  5. 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.

Activity

  1. asineth0 commented on Sep 13, 2026

    @asineth0

    thanks i just wasted a half hour with this issue

  2. JJLiebig commented on Sep 15, 2026

    @JJLiebig

    Confirmed this still reproduces consistently with @opencode/cli@2.0.3 on Windows 11 Pro, build 26200.

    • Launch directory: C:\code\herdr
    • git rev-parse --show-toplevel: C:/Code/herdr
    • Three fresh sessions failed with Instructions.InitializationBlocked: ... unavailable sources: core/instructions
    • A session using canonical casing under C:\Code\... continued working concurrently through the same background service.
    • opencode debug config launched from the lowercase path already reports the project agent directory as C:\Code\herdr\.agents, showing mixed canonical/non-canonical paths before instruction initialization.
    • The server log starts Git discovery with cwd="C:\code\herdr" and subsequently runs git remote get-url origin with cwd="C:\Code\herdr", matching the casing transition described in this issue.

    This suggests the bug remains present in the current stable 2.0.3 release and is location-specific rather than a generally unhealthy background service.

  3. mariopasquali commented on Sep 28, 2026

    @mariopasquali

    Guys, already got hit by this 4 times, would be awesome to have a fix

  4. neriousy commented on Oct 20, 2026

    @neriousy
    Member

    Fixed by #53349, released in v2.0.24. Instruction loading now handles project roots whose casing differs on Windows (e.g. C:\dev\repo vs C:\Dev\repo), so those sessions no longer fail with InitializationBlocked: core/instructions. If you still see this on v2.0.24 or later, comment and we'll reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions