fix(core): reject invalid UTF-8 directory paths in serve

[extencil]

Issue for this PR

Closes #38235
Closes #37764

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

While running opencode serve, I got a session whose directory ended with two U+FFFD replacement characters: .../bin/��. The file picker rejected that path, and prompt_async failed because FileSystem.realPath tried to resolve it and got ENOENT.

I could reproduce the same path shape with a malformed route segment. For example, __8 decodes to the bytes FF FF, and the non-fatal TextDecoder turns those into ��. The app uses that as the directory, and the SDK sends it as %EF%BF%BD%EF%BF%BD in x-opencode-directory. InstanceContextMiddleware decodes the header, then InstanceStore calls path.resolve() on the relative �� value and ends up with <cwd>/��. That matches what showed up in my log.

I do not have the original browser URL from that run, so __8 is only a minimal reproduction of the bug, not a claim that it was the exact route segment. The database also had older session directories with literal U+FFFD characters, so values like this had already been persisted before.

The fix makes base64Decode use a fatal UTF-8 decoder. The app's decode64 wrapper already handles decode errors, so malformed route segments now go through the existing invalid-route behavior. For values that already contain U+FFFD, the HTTP routing, location, decoded instance context, and InstanceStore.load/reload paths fall back to process.cwd() instead of initializing that directory.

How did you verify your code works?

• bun test test/server/httpapi-workspace-routing.test.ts test/project/instance.test.ts: 18 passed, 0 failed
• bun turbo typecheck: 30 tasks passed
• bun run script/build.ts --single --skip-embed-web-ui --skip-install: built the Linux x64 binary and passed its --version smoke test
• Reproduced __8 -> �� -> %EF%BF%BD%EF%BF%BD -> <cwd>/�� with the old decoder, then confirmed the fatal decoder rejects the same bytes
• Manually checked a valid non-ASCII base64 round trip

I reproduced the original failure with ./opencode serve --log-level DEBUG --pure --print-logs. I have not rerun that browser flow after adding the final instance-loading guard.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[chardskarth]

Hi @extencil,

I am also experiencing this error and I tried your branch but still see the error :(

[chardskarth]

1.16.2 version is working for me - Just want to add in possible investigation.

[cuddly-guacamole]

Thanks for this fix. I hit the same bug and want to share a precise repro + a gap this PR doesn't cover.

Repro (no malformed URL needed): opening /app/ matches the /:dir route with dir="app". atob("app") does not throw in Chromium — it decodes to bytes [0x6A, 0x9A], and the non-fatal TextDecoder turns 0x9A into U+FFFD. Result: "j�" becomes the working directory (persisted into the localStorage draft tab), and every prompt fails with FileSystem.realPath (.../j�) ENOENT.

Gap: this PR only guards the server (fatal decoder + cwd fallbacks). The client-side decodeDirectory() in packages/app/src/pages/directory-layout.tsx still accepts the decoded U+FFFD value and writes it to the draft tab in localStorage — which explains why the error persists after applying this branch (see @chardskarth's comment). Existing polluted drafts survive a server-side fix.

Suggested one-line client-side complement:

export function decodeDirectory(dir: string): ProjectDirString | undefined {
  const decoded = decode64(dir)
  if (!decoded) return
  if (base64Encode(decoded) !== dir) return // round-trip check, same pattern as requireServerKey()
  return ProjectDirString.make(decoded)
}

Verified on 1.18.16 and 1.17.20 (Windows, web UI). Happy to open a separate PR for the app-layer part if useful.

[chardskarth]

Thanks for checking @cuddly-guacamole ! I tested this one line addition and I can confirm this works for me.