Symlinked project directories break after 8a95be4 (realpath resolution)

[brndnblck]

Description

Commit 8a95be4 introduced Filesystem.resolve() which calls realpathSync.native() to canonicalize the project directory. This dereferences symlinks. The resolve call was added to the server request middleware (server.ts), the instance cache (instance.ts), and the TUI entry point (thread.ts). The app frontend (directory-layout.tsx) was also updated to call /path, detect the resolved directory, and redirect the URL slug to match.

When OpenCode is launched from a directory that is (or is inside) a symlink, the client initially sends the symlink path but the server resolves it to the real target path. This creates a mismatch: the instance is keyed by the real path, but the frontend may still reference the symlink path in some flows. The result is that sessions are broken and AI output is not visible. Launching from the real (non-symlink) path works fine.

Plugins

None

OpenCode version

Unknown; regression introduced by 8a95be4

Steps to reproduce

1. Create a symlink to a repo: ln -s /path/to/real/repo /path/to/link/repo
2. cd /path/to/link/repo (confirm pwd shows the symlink path).
3. Start OpenCode (TUI or app).
4. Create/open a session and send a prompt.
5. Observe: session UI appears broken and AI output is not visible.
6. Repeat from the real path (cd /path/to/real/repo) and note it works normally.

Screenshot and/or share link

N/A

Operating System

macOS 26.3.1 (Build 25D2128)

Terminal

Ghostty 1.2.3 (stable)

[github-actions]

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

• Does OpenCode not recognize the reference paths of symbolic links? in windows 11 #16342: Same question about OpenCode not recognizing symlinked paths on Windows 11
• [regression] opencode 1.2.21 freezes on session start if the current working directory is a symlink #16522: Explicit regression report — opencode 1.2.21 freezes on session start when CWD is a symlink
• TUI renders blank responses when launched from a symlinked directory #16528: TUI renders blank responses when launched from a symlinked directory
• OpenCode 1.2.21 stops working in WSL folders that are symbolic links to Windows paths #16596: OpenCode 1.2.21 stops working in WSL folders that are symbolic links to Windows paths
• TUI renders blank responses on systems where /home is a symlink (Fedora Atomic/Silverblue/Aurora) #16603: TUI renders blank responses on systems where /home is a symlink (Fedora/Silverblue)
• Interactive TUI hangs in macOS temp directories due to /var vs /private/var path split #16607: Related — macOS /var vs /private/var hang caused by the same realpath dereferencing mechanism

Several of these are closed, which may mean the issue was addressed or tracked elsewhere. If your specific scenario (Windows junctions/symlinks broken by commit 8a95be4) is not covered by the above, please clarify the distinction so maintainers can track it separately.

[brndnblck]

@Hona can we revert in the meantime? This is going to break a lot of people.

[brndnblck]

For others running into this issue, I recommend downgrading and pinning in homebrew in the meantime:

# Checkout the 1.2.20 formula from the tap history
git -C "$(brew --prefix)/Library/Taps/sst/homebrew-tap" checkout f54da00 -- opencode.rb

# Reinstall using the older formula
brew reinstall opencode

# Pin to prevent brew upgrade from bumping back to 1.2.21
brew pin opencode

# To undo later once the bug is fixed:
brew unpin opencode
brew update && brew upgrade opencode

[jmylchreest]

Fix submitted in #16650 — adds fs.realpathSync() to Instance.provide() and Instance.reload() so symlinks resolve to canonical paths before cache lookup. This prevents duplicate Instance contexts and restores Bus event routing.

[Hona]

So testing on my linux VPS 1.2.20 and 1.2.22 both resolve the symlink

is this just breaking desktop?

im trying to isolate what exactly broke on linux here

[Hona]

@jmylchreest your PR has a lot of unrelated changes in it?

[jmylchreest]

Updated fix PR: #16651 (clean branch from dev, replacing the earlier #16650 which included unrelated commits).