22bcd7d4b9cf15c3e413e6567e2cbe855cd0ea87
Two defects, one cause: the session type declared two fields opencode 1.17.9 does not return. `GET /session` returns `directory` at the top level. There is no `location` object and no `metadata`. Re-verified by reading the live server rather than the type. So `metadata.officer.cwd` was compared against `undefined` for every session and the list filter matched nothing — and since `cwdOf` substitutes a default when no `?cwd=` is given, the `!cwd` escape never fired either. There was no configuration in which an OpenCode session appeared in /chat. Confirmed against the running server: 7 sessions present, 0 returned, and the `OpenCode` badge in SessionList was unreachable code. Now 1 of 7 is listed under the default chat dir, the other 6 correctly filtered to their own directories. And `location?.directory ?? ''` was likewise always '', so resuming a session reported no cwd and relocated the conversation to the default chat dir — which matters because OpenCode rebuilds its working-directory system prompt every turn. Detail now reads the session's own record via a new `getSession`, alongside the transcript. `officerMeta` and the `metadata` tag are gone rather than fixed: the only writer of that tag (`client.createSession`) has no callers, because the sidecar creates sessions with `opencode run --dir`. Tagging would have been a second source of truth for something `directory` already answers. docs/opencode-parity.md B1 and B3. Its suggested fix — derive from `location.directory` — was written against a field that does not exist; the doc asked for the version to be checked first, and this is why. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
No description provided
42 MiB
Languages
TypeScript
90.9%
Shell
4.7%
JavaScript
4.1%
CSS
0.2%
HTML
0.1%