Every AI coding CLI Influxx supports writes its session history to disk in its own shape, and Influxx's job is to find the live session for your current worktree and turn its transcript into chat bubbles. For Codex, Claude, and Grok, that job fits a predictable pattern: read one file, find an embedded working directory, match it against your cwd. Kimi CLI doesn't fit that pattern — its session identity lives in one file, its transcript in another, and its transcript isn't even one row per message. Influxx 1.2 ships a dedicated Kimi detection module instead of forcing it into the same shape, because the honest fix for a provider that's genuinely different is a narrow exception, not a bigger abstraction.
The Shape Every Other Provider Fits
Codex writes rollout files where the working directory is embedded directly in a session_meta record near the top of the file — Influxx reads the first few kilobytes, pulls out payload.cwd, and compares it to your worktree path. Claude (and OpenClaude) encode the working directory straight into the directory name itself, so finding a session is a matter of building the same slug and listing what's inside. Grok keeps a single active_sessions.json next to its session store and looks up the current cwd there. All three converge on the same move: read a source of truth, extract an identifying path, pick the newest match by modification time.
That convergence is what makes a shared pattern worth having. It's not a coincidence that all three read a single artifact per candidate session — it's what let the general provider-integration model be a declarative one in the first place.
Where Kimi's Session Data Actually Lives
Kimi Code doesn't embed the working directory in the transcript at all. Instead, discoverKimiActiveSession has to walk every state.json file nested under the sessions directory, derive a session id from its path, then open a separate file — session_index.jsonl, resolved relative to that state file — to read a workdir-by-session-id map. Only after that join can it tell whether a given session belongs to the current worktree at all.
Even once a session matches, the transcript to actually tail isn't the state file. The code calls kimiPrimaryAgentWirePath to derive the real conversation log, a wire.jsonl file, from the parsed state record — falling back to the state file's own mtime only if that wire file doesn't exist yet. Where Codex needs one file and Claude needs one directory listing, Kimi discovery is a three-file join: state, index, and wire, each answering a different question.
"The first version of this tried to keep Kimi in the same declarative table as everyone else by adding an optional 'index file' field to the shared config. It technically worked, but every other provider now had a field they'd never use, and the one provider that needed it still needed custom code to do the join. That's the sign the abstraction is leaking, not helping."
— Devon Achterberg, Staff Engineer, Native Chat Integrations at ETAPX
A Transcript That Isn't One Row, One Message
Assuming discovery finds the right wire.jsonl, decoding it hits a second mismatch. Codex, Claude, and Grok transcripts are close to one JSON line per message. Kimi's wire log is explicitly event-sourced — a comment in transcript-line-decoders-kimi.ts says as much: streaming content.part chunks can surface as separate assistant bubbles until a future fold on step.end, and user turns arrive as complete context.append_message records. The decoder has to branch on an outer envelope type first, then, for loop events, branch again on an inner event type — content.part, tool.call (or tool_call), tool.result (or tool_result, tool.output, tool_output). Kimi's wire format uses both dot and underscore naming for the same concepts depending on which code path emitted the event, and the decoder has to accept all of them or silently drop real tool activity.
Filtering Out What Isn't Really From the User
Kimi also injects synthetic rows into the same stream real user turns arrive on. A context.append_message record with role: 'user' isn't automatically a real user turn — the decoder checks message.origin?.kind === 'user' and discards anything else, because Kimi uses the same envelope for system-reminder injections. Skip that check and Influxx would render internal reminder text in the chat panel as if you'd typed it yourself. None of the other three providers need an origin check like this; their user-message records don't share a channel with injected system content.
Pairing Calls With Results When Order Isn't Guaranteed
Tool call/result pairing is normally straightforward: a call comes in, a result follows, match them in order. Kimi breaks that assumption by emitting parallel tool calls, so the decoder resolves a toolCallId through a long fallback chain — uuid first (both the call and its result tend to share it), then toolCallId, tool_call_id, call_id, and several nested variants under tool, result, and output objects. A code comment marks this explicitly as fixing a real regression: without the id, pairing falls back to FIFO order and breaks the moment the provider reorders results. The same file also has to avoid a second, unrelated bug: an earlier version stored the entire raw wire event as a tool's input, which leaked internal fields like uuid and turnId straight into the chat UI. The current decoder builds a clean input object from args/arguments/input/parameters instead, attaching only the provider's own description text.
Errors Hiding in Different Places
Failure detection has the same fan-out problem. A Kimi tool result can mark failure with isError, is_error, or error as a boolean, or with a status string matching fail or error — and any of those can live on the event root, or nested one level down under result, or under output. A comment ties this directly to an observed bug: real wire rows put the flag under event.result, not the event root, so an implementation that only checked the root silently reported failed tool calls as successful. The decoder also treats a present, non-null, non-false error field on either nested object as a failure signal even when no explicit flag is set.
"I run Kimi Code for most of my agent work because it's fast, and before this update Influxx's chat view for it was genuinely unreliable — tool calls stuck spinning forever, or a failed command showing green like it worked. Now it just matches what I see in the actual CLI. I didn't need to know any of the reasons why, I just noticed it stopped being wrong."
— Renata Solheim, platform engineer at a fintech infrastructure company, Influxx user
The Actual Lesson: Exception, Not Bigger Abstraction
None of these differences are exotic on their own — event-sourced logs, multi-file session indexes, and inconsistent field naming are all things real provider APIs do. What makes Kimi worth a dedicated module rather than a widened shared table is that these quirks compound: the session-discovery join, the event-type branching, the origin filter, the id fallback chain, and the multi-location error check are five separate pieces of provider-specific knowledge that don't map cleanly onto any single config field the other three providers could share. Bolting each one onto the general table as an optional flag would mean every provider carries fields it never reads, and the table stops describing a real shared shape — it just describes Kimi with extra steps. Keeping Kimi's logic in its own kimi-active-session-discovery.ts and transcript-line-decoders-kimi.ts means the shared pattern used by Codex, Claude, and Grok stays legible, and Kimi's real complexity stays contained to the two files that actually need to know about it.
"There's a version of this org that measures itself by how few files exist per integration, and that version would have merged Kimi into the shared table no matter what the code looked like afterward. We'd rather have five honest, readable files than one dishonest, overloaded one. A provider that's genuinely different should look different in the codebase — that's not technical debt, that's the code telling you the truth."
— Marcus Whitfield, VP of Engineering at ETAPX
Frequently Asked Questions
Does this mean Kimi CLI support in Influxx is less reliable than other providers?
No — it means the opposite of what you might expect. The dedicated module exists specifically because Kimi's wire format has more edge cases (event-sourced streaming, parallel tool calls, multi-location error flags) than a shared table could handle correctly, and each of those cases has explicit handling and test coverage.
Why doesn't Influxx just add more optional fields to the shared provider table for cases like this?
Because most of Kimi's quirks — the three-file session join, the dual dot/underscore event naming, the origin-based filtering of injected messages — don't generalize to the other providers. Adding fields only Kimi uses would make the shared table describe one provider's needs disguised as a general shape.
Will every new provider Influxx adds need its own dedicated module like Kimi's?
Not necessarily. Codex, Claude, and Grok all fit the shared declarative pattern today. Whether a new provider needs a dedicated module depends on whether its session and transcript formats actually diverge from that pattern the way Kimi's does.
What happens if Kimi CLI changes its wire format in a future release?
Because the decoding logic is isolated to transcript-line-decoders-kimi.ts, format changes are handled by updating that file's parsing rather than touching the shared decoder path used by other providers.
Does the Kimi decoder show raw internal fields like session or turn ids in the chat view?
No. The decoder deliberately avoids storing the full wire event as tool input specifically to keep internal fields like uuid and turnId out of the chat UI, building a clean input object from the provider's actual arguments instead.
How does Influxx know which session is the "active" one when I have multiple Kimi sessions for the same project?
It matches every session's recorded working directory against your current worktree path, then picks the most recently modified match by file modification time.
The interesting part of this story isn't Kimi's wire format — it's that the codebase was willing to let one provider look different from the other three instead of quietly making the shared abstraction worse for everyone to hide it.
