Summary
When OpenCode is used from Zed via the ACP registry entry, the Recent conversations list appears frozen/stale and does not show newly created sessions.
Switching Zed to custom command mode immediately shows current sessions.
Environment
- Zed (ACP external agent via registry)
- OpenCode 1.2.17
- Registry command entry:
opencode acp (from registry.json)
- Linux (Zorin)
Repro
- In Zed, configure OpenCode via ACP registry (not custom command).
- Create several new conversations in different project directories.
- Open Recent conversations in Zed ACP UI.
- Observe list stays on older items (looks like not saving/updating).
- Switch to custom command mode (
opencode custom type), then re-open Recent.
- Observe current conversations appear.
What I verified locally
- Sessions are persisted in
~/.local/share/opencode/opencode.db (new rows are present).
- In registry mode, the ACP process runs from a registry path and has no explicit workspace cwd.
GET /session (no query) returns the same stale list seen in Zed.
GET /session?directory=<active-project-dir> returns expected current sessions.
This looks like a scope/default-directory mismatch for session listing in registry mode, not a DB write failure.
Suspected fix
Either:
- Have Zed pass active worktree directory when requesting session history, or
- Have OpenCode ACP default
/session behavior be workspace-aware / less dependent on process cwd in registry launches.
Extra signal
In one registry-launched process log I also saw:
setRawMode failed with errno: 5
which may contribute to ACP process instability in some runs.
Summary
When OpenCode is used from Zed via the ACP registry entry, the Recent conversations list appears frozen/stale and does not show newly created sessions.
Switching Zed to custom command mode immediately shows current sessions.
Environment
opencode acp(from registry.json)Repro
opencodecustom type), then re-open Recent.What I verified locally
~/.local/share/opencode/opencode.db(new rows are present).GET /session(no query) returns the same stale list seen in Zed.GET /session?directory=<active-project-dir>returns expected current sessions.This looks like a scope/default-directory mismatch for session listing in registry mode, not a DB write failure.
Suspected fix
Either:
/sessionbehavior be workspace-aware / less dependent on process cwd in registry launches.Extra signal
In one registry-launched process log I also saw:
setRawMode failed with errno: 5which may contribute to ACP process instability in some runs.