Summary
@cortexkit/opencode-openai-auth@0.4.0 can permanently lose its TUI sidebar state after /tmp/opencode-openai-auth/ is removed.
The new cross-process sidebar lock attempts to create:
/tmp/opencode-openai-auth/sidebar-state.json.sidebar-write.lock
before ensuring its parent directory exists. This throws ENOENT, prevents the actual sidebar-state write from running, and leaves the sidebar blank.
Downgrading to 0.3.4 resolves the issue.
Environment
- OS: Linux
- /tmp: tmpfs
- OpenCode: 1.17.18 (custom build)
- @cortexkit/opencode-openai-auth
- broken: 0.4.0
- working: 0.3.4
Error
ENOENT: no such file or directory, open
'/tmp/opencode-openai-auth/sidebar-state.json.sidebar-write.lock'
I observed 54 occurrences in OpenCode logs during one session.
Actual behavior
- /tmp/opencode-openai-auth/ is removed by reboot, tmp cleanup, or manual deletion.
- A sidebar quota/routing update runs.
- The plugin tries writeFile(lockPath, ..., { flag: "wx" }).
- The parent directory does not exist, so it throws ENOENT.
- The normal sidebar writer—which does call mkdir(dirname(file), { recursive: true })—is never reached.
- getSidebarState() returns the empty default state because sidebar-state.json is missing.
- The OpenCode-auth sidebar shows no quota/account/routing data.
Expected behavior
The plugin should recreate /tmp/opencode-openai-auth/ automatically after tmp cleanup, reboot, or first run, then write the lock and sidebar state normally.
Likely cause
In the v0.4.0 sidebar write flow:
acquireSidebarWriteLock()
-> writeFile(lockPath, { flag: "wx" }) // fails if parent is absent
-> writeMergedSidebarState()
-> doWriteSidebarState()
-> mkdir(dirname(file), { recursive: true }) // too late
The parent directory must be created before acquiring the lock, or lock acquisition itself must ensure:
await mkdir(dirname(lockPath), { recursive: true })
before attempting the exclusive lock-file write.
Temporary workaround
install -d \
-m 700 \
-o "$USER" \
-g "$(id -gn)" \
/tmp/opencode-openai-auth
Confirmed writable with:
touch /tmp/opencode-openai-auth/sidebar-state.json.sidebar-write.lock \
&& rm /tmp/opencode-openai-auth/sidebar-state.json.sidebar-write.lock
This is not durable because /tmp can be cleared again.
Regression check
- 0.4.0: lock ENOENT errors and blank sidebar after the temporary directory is absent.
- 0.3.4: no cross-process sidebar lock path; sidebar works normally.
A fix that creates the parent directory before lock acquisition should resolve this.
Summary
@cortexkit/opencode-openai-auth@0.4.0can permanently lose its TUI sidebar state after/tmp/opencode-openai-auth/is removed.The new cross-process sidebar lock attempts to create:
before ensuring its parent directory exists. This throws ENOENT, prevents the actual sidebar-state write from running, and leaves the sidebar blank.
Downgrading to 0.3.4 resolves the issue.
Environment
Error
ENOENT: no such file or directory, open
'/tmp/opencode-openai-auth/sidebar-state.json.sidebar-write.lock'
I observed 54 occurrences in OpenCode logs during one session.
Actual behavior
Expected behavior
The plugin should recreate /tmp/opencode-openai-auth/ automatically after tmp cleanup, reboot, or first run, then write the lock and sidebar state normally.
Likely cause
In the v0.4.0 sidebar write flow:
acquireSidebarWriteLock()
-> writeFile(lockPath, { flag: "wx" }) // fails if parent is absent
-> writeMergedSidebarState()
-> doWriteSidebarState()
-> mkdir(dirname(file), { recursive: true }) // too late
The parent directory must be created before acquiring the lock, or lock acquisition itself must ensure:
await mkdir(dirname(lockPath), { recursive: true })
before attempting the exclusive lock-file write.
Temporary workaround
Confirmed writable with:
touch /tmp/opencode-openai-auth/sidebar-state.json.sidebar-write.lock \ && rm /tmp/opencode-openai-auth/sidebar-state.json.sidebar-write.lockThis is not durable because /tmp can be cleared again.
Regression check
A fix that creates the parent directory before lock acquisition should resolve this.