v0.2.7
- fix(kimi): bind lazily-created sessions
kimi-code creates its session at the FIRST prompt, not at process
start — measured 4m30s after launch on a live pane. The process-
ownership window required creation within 30s of the process start,
so both the index match and the bucket fallback rejected a perfectly
matching idle session (proc-fd short-circuits while kimi is active,
which is why only IDLE sessions flickered). The daemon then looped
bind -> fail -> remove every reconcile tick, rendering the flashing
unnamed kimi card in the sidebar.
The window is now one-sided: any session created at or after the
process start (minus clock slack) is process-owned. Sessions created
before the process remain rejected, and the resume path is unchanged.
Co-Authored-By: codex executor noreply@openai.com
- chore: 0.2.7
Fixes the flickering unnamed kimi card in the sidebar: kimi-code
creates its session at the first prompt — potentially minutes after
the process starts — but the session locator only accepted sessions
created within 30 seconds of process start. Idle kimi sessions were
therefore rejected on every locate, and the daemon looped
bind/fail/remove once per second, flashing a half-built card. The
ownership window is now one-sided (created at or after process start),
stale sessions from earlier runs are still rejected, and resumed
sessions bind exactly as before.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
- fix(kimi): resolve sessions by the reported id, end-to-end
The locate trait has always carried a session identifier, but the
production chain passed the PANE id and the kimi locator ignored the
parameter entirely — inferring sessions from cwd and process
ownership. With the ownership window one-sided, two kimi processes
sharing a cwd could cross-bind. The herdr-reported session id (byte-
identical to session_index.jsonl's sessionId and the session dir name)
now flows from SidecarAdapter::bind through the watcher lifecycle into
the kimi locator, which resolves it first: trusted exact index match,
then a bounded bucket scan. A reported id with no on-disk match is a
retryable error, never an inference — and the supervisor's refresh
keeps the reported session rather than re-inferring. Legacy callers
without a reported id keep the inference chain unchanged.
Addresses chatgpt-codex-connector review on PR #3 and the codex-verify
findings on the first attempt (id never plumbed; refresh bypass;
miss-fallback cross-bind).
Co-Authored-By: codex executor noreply@openai.com
Co-authored-by: codex executor noreply@openai.com
Co-authored-by: Claude Fable 5 noreply@anthropic.com
What's Changed
- fix(kimi): bind lazily-created sessions by @winoooops in #3
Full Changelog: v0.2.6...v0.2.7
