Some Git for Windows installations have bash.exe only at
<root>\usr\bin\bash.exe while <root>\bin\bash.exe does not exist.
Add usr\bin\bash.exe candidates alongside each bin\bash.exe entry in
both the hardcoded fallback list and the git.exe inference logic.
Also add @moonshot-ai/kimi-code-sdk to the changeset since the SDK
bundles agent-core code and calls detectEnvironmentFromNode() on
session creation, so Windows SDK users also need this fix.
* feat(glob): add brace expansion and fix backslash escaping
- add brace expansion support for glob patterns with up to 64 sub-pattern cap
- remove up-front rejection of pure-wildcard and **/ prefix patterns; rely on 100-match cap\n- fix backslash escape handling in globPatternToRegex and inside character classes
- include matched count in truncation messages\n- show glob pattern, path, and include_dirs in TUI tool-call headers
* fix(kaos): use charAt to avoid TS strict undefined index error
* feat(tui): add /provider command, custom registry import, and tabbed model selector
- add "/provider" slash command for managing AI providers with CRUD UI
- add custom registry import via api.json URL and Bearer token
- introduce tabbed model selector grouped by provider
- add fetchCustomRegistry and applyCustomRegistryProvider in oauth package
- replace deprecated "/connect" command with unified "/provider" flow
- update provider and slash-command documentation
* feat(tui): background provider model refresh at startup
- add `refreshAllProviderModels` utility supporting managed OAuth, open platforms and custom registries
- wire background refresh into `KimiTUI` startup via `AuthFlowController`
- add `providerSwitchHint` option to `ModelSelector` and enable it in `TabbedModelSelector`
- update `TabbedModelSelector` hint wording from "switch" to "provider"
* chore(flake): simplify nix build and add ci validation
- Replace dynamic pnpm-workspace.yaml parsing with hardcoded workspacePaths
and workspaceNames to reduce format assumptions
- Remove update-pnpm-deps script and kimi-code-pnpm-deps package; use
lib.fakeHash for standard hash mismatch workflow
- Remove nodejs_latest fallback in nodejsFor, hardcode to nodejs_24
- Add nix-build CI workflow that posts hash-mismatch details to PR comments
- Remove unused Nix installation step from release.yml
- Add workspace maintenance note to AGENTS.md
* feat(cron): render scheduled reminders in TUI and expose fired events
- add CronMessageComponent for distinct cron transcript entries in TUI
- emit cron.fired events from agent-core and expose via node-sdk
- report cron fire times with local ISO timestamps including timezone offsets
- render cron_job and cron_missed origins during session replay instead of skipping
- handle warning events in CLI and session event handler
* docs(cron): clarify that users must ask the model to manage cron tasks
- cron-create.md: instruct model to proactively tell users how to cancel/modify reminders
- cron-list.md: add guideline that users cannot directly manage cron tasks\n- cron-delete.md: emphasize users must ask model to cancel reminders
When the user interrupts running tools or parallel subagents, the tool_result
fed back to the model was a neutral `Tool "X" was aborted` or a weak "stopped by
the user", so the model treated it as a system fault and speculated about
capacity/concurrency limits instead of recognizing a deliberate stop.
Carry a UserCancellationError as the AbortSignal reason from the cancel sites
(Turn.cancel/abortTurn, SessionSubagentHost.cancelAll) through to the message
sites (tool-call settle paths and the AgentTool catches), which now emit an
explicit "deliberate user action, not a system error/timeout/capacity limit"
message. Aborts propagated from another signal (e.g. a subagent's deadline via
waitForCurrentTurn) carry their original reason, so a timeout is not mislabeled
as a user interruption. The telemetry outcome classifier matches the new
"manually interrupted" phrase to keep counting these as cancelled.
* feat: force adaptive thinking via KIMI_MODEL_ADAPTIVE_THINKING
Add the KIMI_MODEL_ADAPTIVE_THINKING env var and a matching
adaptive_thinking model-alias field that force adaptive thinking
(thinking: { type: 'adaptive' }) on or off, overriding the Anthropic
model-name version inference.
This lets custom-named staff endpoints that back an adaptive-capable
model opt in even when the model name does not encode a parseable Claude
version (which would otherwise fall back to budget-based thinking).
The kosong AnthropicChatProvider resolves the adaptive decision once in
withThinking() as `_adaptiveThinking ?? supportsAdaptiveThinking(model)`
and threads it through clampEffort/supportsEffortParam so forced adaptive
also unlocks the max effort level.
* fix: make adaptive_thinking imply the thinking capability
A model alias that sets adaptive_thinking=true (or env
KIMI_MODEL_ADAPTIVE_THINKING=true) without listing a thinking
capability previously resolved to thinking=false for custom-named
endpoints not in the capability catalog. The model picker then
classified the alias as "thinking unsupported" and forced thinking
off (persisting default_thinking=false).
Treat a forced adaptive flag as advertising the thinking capability
in resolveModelCapabilities, so the config.toml one-field opt-in
agrees with the KIMI_MODEL_* env path (which already defaults
capabilities to include thinking).
* fix: honor adaptiveThinking in the model picker, not the capability resolver
The earlier resolveModelCapabilities change had no observable effect:
modelCapabilities.thinking is consumed only for completion-budget and
media gating, never to decide whether thinking is dispatched or whether
the model picker offers a thinking toggle.
The mechanism that actually forced thinking off for an adaptive_thinking
alias is the TUI model picker, which reads ModelAlias.capabilities
directly (availableModels comes straight from config.models). Revert the
resolver change and instead make thinkingAvailability() treat
adaptiveThinking=true as a thinking toggle, so a custom-named config.toml
alias configured with only `adaptive_thinking = true` is no longer
classified "unsupported" (which forced thinking off and persisted
default_thinking=false on select). The KIMI_MODEL_* env path was already
covered by DEFAULT_CAPABILITIES.
* feat(plugin): install plugins from a GitHub repository URL
Allow `/plugins install <github-url>` (and marketplace `source` entries) to
take a GitHub repo URL directly. A new `github` source kind joins the
existing `local-path` and `zip-url` kinds.
Recognized URL forms (parsing in source.ts):
- `https://github.com/<o>/<r>` — bare; resolves to latest
release tag, falling back
to default branch HEAD.
- `https://github.com/<o>/<r>/tree/<ref>` — branch / tag / SHA;
value passed to codeload
in its short form so the
backend resolves either.
- `https://github.com/<o>/<r>/releases/tag/<tag>` — explicit tag, uses
refs/tags/<tag> to avoid
same-named-branch ambiguity.
- `https://github.com/<o>/<r>/commit/<sha>` — explicit commit SHA.
The resolver deliberately avoids `api.github.com`: its 60/hour anonymous
quota is shared with every other tool on the egress IP (browser, gh CLI,
IDE integrations) and a first-time install failing because some other tool
ate the budget is unacceptable UX. Instead we:
- GET `github.com/<o>/<r>/releases/latest` with manual redirect and parse
the `Location` header (302 → tag URL; 404 → no own release).
- Fall back to `codeload.github.com/<o>/<r>/zip/HEAD` for repos with no
releases (or for forks that inherit upstream tags but have no own release
page, which redirect to bare `/releases`).
- Only treat the explicit 404 from `/releases/latest` as "no release" — 5xx,
403, 429, and any other non-2xx status surface a hard error rather than
silently installing the default branch, so the user knows when transient
GitHub issues changed the install path.
UI changes in the TUI:
- `/plugins install` now shows a live Braille spinner while resolving and
downloading, then flips to a final status that distinguishes Installed
(fresh) vs Updated (same repo identity, new version) vs Migrated (source
changed, e.g. CDN zip-url → GitHub).
- `/plugins list`, the `/plugins` overview, and `/plugins info` show the
install provenance inline. `zip-url` installs now display the URL host
(e.g. `via code.kimi.com`, `via 127.0.0.1:port`) instead of the opaque
`zip-url` literal. GitHub installs show `github <owner>/<repo>@<ref>`.
- Three-tier trust badge driven by the marketplace context recorded at
install time: `official` (green) for `tier: official`, `curated` (blue) for
`tier: curated`, `third-party` (muted) for anything not installed through
the marketplace selector. CLI `/plugins install <url>` always records as
third-party; the marketplace selector passes the tier through. A
re-install replaces the marketplace context: switching to a third-party
source clears the badge, which matches the underlying trust change.
`installed.json` gains optional `github` and `marketplace` fields
(back-compatible). PluginSummary surfaces `source`, `originalSource`,
`github`, and `marketplace` so the TUI can label installs without an extra
round trip to PluginInfo. The SDK's `session.installPlugin(source)` gains
an optional `{ marketplace }` second argument so the marketplace selector
can forward `{ id, tier }` through RPC; the CLI install path omits it.
Tests: 112 plugin-suite tests (URL parser, resolver, store round-trip,
manager integration). The manager integration tests assert codeload URLs
shape (short form for `/tree/<ref>`, explicit `refs/tags/` for
`/releases/tag/`) and verify marketplace context is persisted across
reloads and cleared on a third-party re-install.
* chore(changeset): plugin install from GitHub
* docs(plugins): document GitHub install URLs and trust badges
* fix(plugin): preserve URL-encoded characters in GitHub ref names
Git permits ref characters that have special meaning in URLs — most
notably `#`, which is a valid tag character (e.g. `release#1`) but the URL
fragment delimiter. The resolver decoded the tag from GitHub's
`/releases/latest` 302 redirect Location header and then interpolated the
raw value into the codeload URL. The literal `#1` became a fragment and
the HTTP request reached the server as `…/refs/tags/release` — a wrong or
truncated ref, leading to install failure for a release whose URL was
otherwise valid.
Two symmetric changes:
- The codeload URL builder now splits the ref on `/` (so multi-segment
refs like `feat/foo` keep their path separators) and percent-encodes
each segment.
- The GitHub URL parser now percent-decodes each segment from the URL's
pathname when extracting `/tree/<ref>`, `/releases/tag/<tag>`, and
`/commit/<sha>`. Storage and display see the human-readable Git ref
name; the resolver re-encodes on the way out.
Malformed `%xx` sequences in user-typed URLs are tolerated: we keep the
raw segment so the caller surfaces a normal "ref not found" error
downstream instead of crashing during parse.
* fix: restrict plugin trust badges
* chore: remove fetch when show plugin list
---------
Co-authored-by: qer <Anna_Knapprfr@mail.com>
When converting assistant history to the Anthropic wire format,
convertMessage() dropped any thinking block that had no signature. That
was meant to satisfy api.anthropic.com (which requires a valid signature
on thinking blocks), but it broke Anthropic-compatible backends.
Kimi's Anthropic-protocol endpoint streams thinking without a
signature_delta, yet requires the thinking to be present on a tool-call
turn — once it was dropped, the next request failed with "thinking is
enabled but reasoning_content is missing in assistant tool call message",
making multi-step tool use unusable on those backends.
Preserve unsigned thinking instead, emitting it without a `signature`
field. The two backends are partitioned by signature presence:
api.anthropic.com always supplies a signature (its history takes the
signed branch unchanged), while Kimi never does (its thinking is now
kept). Empty-and-unsigned parts carry nothing and are still skipped.
* feat: define model via KIMI_MODEL_* environment variables
Add a KIMI_MODEL_* environment-variable channel that synthesizes a
provider (__kimi_env__) and model alias (__kimi_env_model__) in memory
and selects it as the default model, without editing config.toml.
Supports provider type (kimi/anthropic/openai), base URL, API key,
context size, capabilities, anthropic max_output_size, openai
reasoning_key, and full thinking settings.
Runtime config reads go through a new loadRuntimeConfig wrapper; the
config.toml write-back paths keep using readConfigFile so the
synthesized model is never persisted back to disk.
* feat: env-model defaults and friendly welcome model name
- KIMI_MODEL_MAX_CONTEXT_SIZE defaults to 262144 (256K) when unset
- KIMI_MODEL_CAPABILITIES defaults to image_in,thinking when unset
- TUI welcome banner shows the model display name / id instead of the
internal __kimi_env_model__ alias key
* fix: never persist env model to config.toml; validate default_thinking
- Strip the synthesized __kimi_env__ provider / __kimi_env_model__ model
(and a default_model pointing at it) in writeConfigFile, so the env model
and its shell API key cannot be persisted via a getConfig -> setConfig
patch round-trip (e.g. running /login or /connect in env-model mode).
- Reject a non-empty but unparseable KIMI_MODEL_DEFAULT_THINKING value
(fail-fast) instead of silently keeping config.toml's existing default.
* fix: preserve on-disk default_model when stripping env model; fix thinking docs
- stripEnvModelConfig restores config.toml's default_model from raw instead of
erasing it when the runtime default points at the env alias, so a real
default_model survives a getConfig -> setConfig round-trip.
- Correct KIMI_MODEL_DEFAULT_THINKING docs: unset follows the global default
(Thinking on), not Off.
* fix: restore env-injected fields to on-disk values in stripEnvModelConfig; update tests for thinking behavior
Introduce a central, env-driven flag registry in agent-core. Each flag is declared once with an id, full env var name, default, and surface. Within agent-core, flags are consulted through a process-global 'flags' constant that reads live process.env. Resolution precedence: master switch KIMI_CODE_EXPERIMENTAL_FLAG > per-feature KIMI_CODE_EXPERIMENTAL_<NAME> > registry default, with lenient boolean parsing via parseBooleanEnv. FlagId is a literal union derived from the registry for compile-time autocomplete and typo-checking.
SDK boundary: KimiHarness.getExperimentalFlags() returns the resolved values over RPC, and the SDK re-exports only the flag *types* — no runtime value crosses the boundary. The TUI caches that snapshot once at startup and reads it synchronously for command gating.
Gate the plugin system behind the 'plugins' flag, off by default: PluginManager.load() consults flags.enabled('plugins'), so when off no installed plugins are loaded or activated, and the TUI /plugins command is hidden from the palette and resolves as an unknown command.
Tests cover the resolver precedence matrix, registry invariants, the FlagId type guard, the live-env singleton, the plugin-load gate, the getExperimentalFlags RPC, and the TUI command gating.
* fix(update): don't report success when native update fails
The native auto-updater spawned `bash -c "curl -fsSL … | bash"`. A
pipeline's exit status is that of its last command, so when curl could
not connect (e.g. a dead proxy) it produced no output, the trailing bash
read empty stdin and exited 0, and the whole command looked successful —
printing "Updated … Restart the CLI" while nothing had been installed.
Run the spawned shell with `set -o pipefail` so curl's non-zero status
propagates. installUpdate() then rejects and runUpdatePreflight() warns
and continues on the current version instead of claiming success.
* chore: add changeset for native update fix
* fix(tui): show real terminal status for background agents
The Agent tool's run_in_background=true call returns a non-error
ToolResult whose body just says "status: running". The transcript
card derived its done/failed badge from that result, so every
terminated background agent — including ones reconcile reclassifies
as lost on resume — kept the green "✓ Completed" label even when
the actual task failed, was killed, or never came back.
Push the real BackgroundTaskInfo.status into the matching Agent
card so the badge reflects what happened. The card's resolver
prefers subagent agentId (live) and falls back to the description
on resume; on resume the apply step also runs after replay
finishes so the agent group can reach the borrowed components.
Also adds an agent-core regression test that pins live, busy,
group, race, and resume scenarios for the bg notification chain.
* fix(tui): also propagate bg agent terminal status to standalone cards
Standalone Agent cards (only one Agent tool call in a step, never
upgraded into an AgentGroupComponent) bypassed the previous
`setBackgroundTaskTerminalStatus` path: the standalone header reads
`getDerivedSubagentPhase`, which still derived `done` from the
non-error spawn-success ToolResult, and the method did not request
a header/content rebuild. Lost/failed/killed bg agents in this
shape still rendered as `✓ Completed`.
Thread the override through `getDerivedSubagentPhase`, populate
`subagentError` with the friendly failure message so both render
paths share one source of truth, and trigger the same header +
content rebuild that `onSubagentFailed` does. Also include the
override in `hasSubagentState` / the subagent-block early-return
so a replayed solo bg agent (no replayed subagent block, no
sub-tool activity) switches to the subagent-aware layout instead
of the generic `Used Agent` rendering.
Adds two standalone-render regression tests so the path no longer
relies on the grouped snapshot to stay correct.
* feat(agent-core): make resume actionable from the lost-task notification
A backgrounded subagent that ends as `lost`/`failed`/`killed` is
already a soft-recoverable thing — `subagentHost.resume` will
reanimate the persisted Agent instance — but the LLM had to dig
through the original spawn-success ToolResult to find the right id
and figure out the recovery shape on its own. The two look-alike
identifiers (the BackgroundManager `task_id` aka `source_id`, and
the `subagentHost` `agent_id`) regularly got confused in practice.
Surface what the model needs at the moment of decision:
- Add `agent_id` as a top-level `<notification>` attribute for
agent-* tasks, so the right id is structural, not buried in
prose. Render path keeps backward-compat by omitting the
attribute when no agent_id is known (bash tasks, old sessions).
- On non-success agent terminal states, append a recovery
paragraph to the body: the precise `Agent(resume=...)` call,
the disambiguation between `agent_id` and `source_id`, the
`run_in_background` option, and what state survives the
restart vs. what may need to be redone.
- Tighten the spawn-time `resume_hint` with the same
disambiguation and an explicit pointer at the
`task.lost`/`task.failed`/`task.killed` recovery trigger.
- Persist `agent_id` and `subagent_type` in PersistedTask so the
recovery body still works after a session restart, where
in-memory `BackgroundTaskInfo.agentId` would otherwise be
undefined. Optional fields keep the disk schema
forward/backward compatible — pre-PR records load without
them and silently fall back to the original short body.
* fix(tui): route bg-agent terminal events by stable agent_id, not description
`tc.subagentAgentId` is left undefined for every backgrounded agent.
`handleSubagentSpawned` early-returns for `runInBackground` before
calling `tc.onSubagentSpawned`, and the wire replay path drops the
`subagent` block entirely (`toolCallFromReplayMessage` returns only
id/name/args). So the `agentId` branch in
`applyBackgroundTaskTerminalStatus` never matched in practice, every
call fell through to the description-based fallback, and the
persisted `agent_id` we added in the previous commit was effectively
dead. That fallback also has a real failure mode: if a foreground
Agent and a backgrounded Agent share the same `args.description`,
the only candidate found is the live (unrelated) card, which gets
incorrectly relabeled as the lost task's terminal state.
Parse `agent_id: agent-N` out of the AgentTool spawn-success
ToolResult body inside `getSubagentAgentId` so the id is always
recoverable, regardless of whether the in-memory subagent metadata
was ever populated. Foreground and backgrounded Agent cards now
carry distinct ids and route correctly.
Also pipe the real `subagent.failed` error through to the parent
card. The background branch of `handleSubagentFailed` previously
only appended the dedicated transcript entry; the parent Agent
card was left with the generic "Background agent failed" written
by the later `background.task.terminated` event. Add an optional
`errorText` to `setBackgroundTaskTerminalStatus` /
`applyBackgroundTaskTerminalStatus` and pass `event.error` through
on the failed branch — the real reason now reaches both the card
and the entry.
* fix(tui): treat agent_id as authoritative when matching bg terminal events
Previously `applyBackgroundTaskTerminalStatus` always tried agent_id
first and then fell back to description match on miss. That fallback
caused two cross-card bugs:
1. On resume, `applyTerminalBackgroundAgentStatuses` iterates every
persisted terminal task, including ones whose tool calls fell
outside the `REPLAY_TURN_LIMIT` window and were never mounted.
Description fallback could route an old `lost` status onto an
unrelated recent Agent card sharing the same `args.description`.
2. During the live spawn → terminate window, the same card briefly
lives in both `_pendingToolComponents` and `transcriptContainer`.
A description-only walk visits the same component twice and flags
itself ambiguous, dropping the otherwise unambiguous update.
When `args.agentId` is provided we now match only by id and skip on
miss. With `getSubagentAgentId` already parsing `agent_id: agent-N`
out of the spawn-success ToolResult, the id path is reliable for
both live and resume even though `tc.subagentAgentId` is never
populated for backgrounded agents. Description fallback is preserved
solely for old pre-PR sessions whose persisted records lack
`agent_id` — same best-effort behavior as before.
A mid-stream SSE drop surfaces as a raw undici `TypeError: terminated`, which was classified as a non-retryable generic error and failed the turn on the first attempt. Route raw transport-layer errors through the connection-error heuristic so a dropped stream becomes a retryable APIConnectionError and is retried transparently. User aborts (ESC) are unaffected — the retry loop checks the abort signal before retrying.
Related to #149.
The `/status` and `/usage` "Plan usage" rows previously rendered the
progress bar from the used ratio while labelling it "X% left", so the
bar direction and the number disagreed.
Display "X% used" instead, aligning the number with the bar, and move
the reset hint to the right without parentheses to mirror the web
console layout.
Merge turnId/step into a single `turnStep` field ("0.1") and
attempt/maxAttempts into `attempt` ("2/3"), and drop the
messageCount/toolCallCount fields. The per-request `llm request`
line goes from up to 8 fields down to ~3; the `llm config` line
(including thinkingEffort, logged for all providers) is unchanged.
