Smoke testing found the start review could be bypassed: the approval
hook gave up when the project-level definition was invalid, while
FlowStartTool's execution fell back to a valid user-level definition
and started the run — no card, no consent. And even when the card did
show, approval and execution each read the file independently, so the
blueprint the user approved was not necessarily the one that ran.
Close the gap in three layers: the hook now falls back to the user
level exactly like the tool; an approved review snapshots the reviewed
definition per toolCallId (one-shot, epoch-guarded like gate
approvals) and FlowStart's execution starts from that snapshot instead
of re-reading the file; and FlowStart must be the only call in its
response, so a sibling Write cannot rewrite the definition mid-review.
A stale-epoch guard voids a review left open across an undo.
The builtin /flow drafting skill also stopped silently shadowing a
user or project skill named flow: it now registers through the builtin
channel (lowest-priority source, experimentalFlag-gated — the tower
skill's pattern), so a same-named user skill wins and the session and
workspace listings agree without hand-wiring.
Non-TUI fronts catch up: acp-server renders the start-review blueprint
and offers sovereignty options without allow-always; the VS Code
bridge extends flow provenance to the start card, so a real rejection
carries its label and a session-scope answer degrades to one-shot.
The drafting skill also clarifies that calling FlowStart yourself is
the rule on this path, not a contract violation.
/flow <task> now works without a predefined definition: a built-in
drafting skill (contributed first by FlowsSkillSource while the flag is
on, and mirrored by the workspace skills route) walks the model through
turning the task into a staged definition under .kimi-code/flows/,
refining it with the user, and submitting FlowStart. The skill body
carries the drafting principles, the exact definition format, and the
full supervisor contract, so a drafted run starts with the same
contract as an activation-started one.
Confirmation is mechanical, not conventional: a FlowStart call now
raises a flow_start_review approval before executing — the hook loads
and validates the definition (project over user level, via the shared
validateFlowDefinitionText) and shows the parsed blueprint (stages,
gates, objectives, completion criteria, source path, task). Approving
starts the run; rejecting with feedback sends the supervisor back to
revise the definition; a plain rejection stops the turn. Activation
auto-starts never call FlowStart and stay approval-free; auto mode
skips the review; an unreadable or invalid definition skips the card
and lets the execution error guide the model instead.
The flow flag now defaults to on (KIMI_CODE_EXPERIMENTAL_FLOW=false
disables it); token-count assertions, tool snapshots, and the
flag-off tests shift accordingly.
* feat(kimi-code): add China/International region selection for OAuth login
- Add region profiles (cn/overseas) and resolver in @moonshot-ai/kimi-code-oauth:
env override → persisted login host → install-channel marker → default cn
- /login now offers Kimi Code (China) / Kimi Code (International); the CLI
login entries (kimi login, kimi acp --login) accept --region cn|overseas
- Update/plugin/site/telemetry endpoints derive from the selected region;
plugin trust list covers both .com and .ai hosts
- kap-server: POST /oauth/login accepts an optional region; new GET /oauth/region
* fix(oauth): keep an explicit default-slot login ahead of the install marker
A China login persists no oauthHost (the default credential slot carries
no host trace), so after switching back from International the resolver
fell through to a stale overseas install marker. Treat a persisted
default-slot oauth ref (key === oauth/kimi-code) as an explicit-cn signal
that outranks the marker; getRegion() on the v2 side mirrors it.
* fix(agent-core-v2): thread the default-slot key through capability region resolution
Capability installs resolved the region from the persisted oauthHost only,
so an explicit China login (which persists no host) lost to a stale
overseas install marker. Pass the oauth ref key through as well, matching
getRegion(). Also move the region contract notes into the auth.ts file
header per the package comment convention.
* fix(agent-core-v2): honor the region-marker opt-out for the telemetry endpoint
Hosts that set KIMI_CODE_REGION_MARKER=off (the desktop embedded server)
skip the install marker in getRegion(), but the default telemetry endpoint
still consulted it, so a stale overseas marker could split the reported
region from the telemetry destination.
* feat(cli): show region site domains in login platform selector
* chore: reword oauth login changesets
* fix: honor the region marker opt-out in the CLI and capability resolvers
* refactor: rename login region values to mainland-cn and global
* fix: keep the --region help text in English
* fix: simplify the --region help text to site domains
* feat: drop the suggested login platform order
* feat: split a browser-safe region profile table out of the region resolver
* Revert "feat: split a browser-safe region profile table out of the region resolver"
This reverts commit a037b1143e.
* fix: read the install marker from the bootstrapped home directory
* fix: resolve the server plugin marketplace from the active login region
* feat: expose the login region option through the klient auth facade
* fix: drop a comment from the v2 auth region test
* fix: keep scoped base-only logins on their environment for a bare login
* fix: invalidate the region cache on the provider-manager logout path
* fix: route client-config fetches through the active region profile
* fix: resolve the telemetry endpoint per flush so a login region switch applies in-process
* test: expect the telemetry endpoint resolver in the CLI init assertions
* fix: resolve the default telemetry endpoint from the bootstrapped home
* chore: reword the oauth login changeset around the two login methods
* chore: trim the oauth login changeset to the headline
* feat: let hosts override the region marker env through the server bootstrap env bag
Conflicts were all generated or baseline-tracking artifacts: the wire
manifest is regenerated (now including flow_run.jumped), the tool
snapshot tests are re-recorded, and the compaction token baselines are
re-shifted on top of main's new values (+11 for the FlowJump tool).
* fix(vscode): multi-select question jumps to next after only one answer selected
* chore: add changeset
---------
Co-authored-by: gaoyuan <gaoyuan@moonshot.ai>
The supervisor can now move an active run to another stage: backward
to redo work whose conclusion was invalidated, forward to skip stages
that do not apply to the task. The definition's frontmatter governs
it via jumps: approval (default — every jump goes through a user
review), free (unsupervised), or disabled (strictly linear, the old
behavior).
- New FlowJump tool (to + reason, both required): validated like the
other flow tools, solo-response only, supervisor-only, flag-gated.
- A durable FlowJumped event moves the undoable stage pointer and
appends a kind: 'jump' record (from/to/reason/decidedBy) to the
retained audit trail; the run epoch bumps on every jump so verdicts
and reminders prepared before it are void, and a revisited stage
re-discloses its reminder.
- The approval flow reuses the gate-review machinery: a new
flow_jump_review display (protocol + kap-server + engine schemas),
epoch-bound reviews, observed-rejection provenance, and no
session-wide approval anywhere (TUI choices, ACP options, VS Code
downgrade all treat jumps like gates).
- GET /sessions/{id}/flow exposes run.jump_policy and the audit
records as a verdict/jump union.
- The supervisor contract's Order rule now teaches FlowJump instead
of mandating abort-and-restart.
Review round 38:
- The activation entry points also reject a flow activation while one
is already queued (pending, not yet consumed at a step head), so two
flow prompts admitted behind a running turn no longer deliver a
second blueprint whose run never starts.
- The VS Code webview downgrades approve_for_session on a flow gate
to a one-shot approval — the engine re-asks every human gate, so
recording a session rule would promise what is never honored
(mirrors the ACP option change).
- The activation-data store no longer caps entries (a concurrent
burst could evict a definition before its SkillActivated consumed
it); failure paths in both entry points now discard what they
stored.
Review round 22:
- FlowAdvance only attaches a flow_gate_review display when the raw
args pass full Zod validation, so an invalid call (for example
whitespace-only evidence that the generated JSON Schema admits)
never opens a gate review; a rejection of such a call is no longer
recorded as a human verdict with an empty criteria list, matching
the approve path where execution revalidation rejects the call.
- The VS Code webview attaches selectedLabel: 'Reject' only to flow
gate rejections; ordinary tool rejections keep the bare shape the
existing adapter contract expects.
Review round 19:
- An undo across a newer run's start restored the previous run's
identity in the undoable state while the world-time gates kept the
newer run's records. The REST route now prefers the gates state's
identity, which is by construction the one the retained records
belong to (identical for a live run).
- VS Code's No now resolves with selectedLabel: 'Reject', so a real
click keeps writing the gate audit while a bare transport-failure
rejection stays unobserved.
Three review findings:
- The TUI gate panel dropped the display's objective/completion, so the
user judged the model-authored checklist with no authoritative
requirement to check it against — the panel now renders both under
the stage context line.
- The VS Code adapter collapsed the whole structured review to a one-
line brief; it now expands flow_gate_review into a multi-line brief
carrying task, objective, completion, per-criterion verdicts,
note, and the advance/finish outcome.
- The stage-reminder deduplication keyed only (flowId, stageIndex), so
restarting the same flow at the same stage (e.g. a new task after an
abort) suppressed the fresh reminder while the stale one kept naming
the old task. The disclosure now carries a content fingerprint —
any reminder-relevant change (task, definition edits) re-injects, and
a pre-upgrade disclosure without a fingerprint re-discloses once.
The human gate borrowed the plan_review display, so every gate approval
rendered as 'Ready to build with this plan?' with plan-mode buttons —
wrong semantics at the flow's core UX moment, and the per-criterion
verdicts (already structured in FlowAdvance args) were flattened into a
markdown blob.
Add a flow_gate_review variant to the display vocabulary (protocol,
agent-core-v2, kap-server wire schema) carrying the stage position,
gate, objective/completion, per-criterion verdicts, and the next stage.
FlowAdvance now attaches the structured payload (the markdown renderer
is gone), and the gate hook matches the new kind.
The TUI approval panel renders it natively: a 'Pass this stage gate?'
header, a flow/stage/progress context line, a ✓/✗ criteria checklist
with dimmed evidence, the supervisor note, and gate-specific choices
(pass / reject with feedback / reject). The vscode adapter's exhaustive
display switches learn the new kind; acp-adapter degrades to its
default approval options by design. Old web bundles fall back to the
generic approval card and can still decide the gate.
* feat(agent-core): unify the v1 MCP management plane
- McpServerRegistry: one config view over global (layered mcp.json),
plugin (manifests, read-only, final effective config), and caller
(SDK-injected) servers; name collisions keep both entries.
- Write plane: add/update/removeGlobalMcpServer mutate the user-level
file and push into live sessions; getGlobalMcpServer returns the
effective config; mutations of read-only entries are rejected.
- testGlobalMcpServer accepts an inline config; addSessionMcpServer
connects a server in one live session with an optional persist flag;
reconnect accepts a replacement config and re-resolves via the registry.
- One process-wide McpOAuthService shared with every session: obtained_at
stamps, offline token state, single-flight and proactive refresh, and
credential events. Sessions self-subscribe in the constructor, so even
initializing sessions see every event; token writes serialize through
the process-local OAuthTokenTransaction per credential identity.
- inspectAppMcpServers + locator-addressed begin/complete/cancel/reset
cover plugin servers; inspection output redacts env/headers to sorted
key lists; locator OAuth ops reject ambiguous shared runtime names.
- The legacy auth-status surface reads the registry (offline by default,
verify=true probes) and never mutates credentials.
- VS Code panel receives source/origin/mutable and hides mutating
actions on read-only entries.
- v2 client facade in node-sdk mirrors the surface over agent-core-v2
(plugin inventory stays v1-only for now).
* fix(agent-core): close the v1 MCP live-session reconciliation gaps
Recompute each live session's MCP target from the registry's runtime
resolution (enabled plugin > project layer > user file; caller injection
shadows everything) behind every config mutation, instead of per-path
patching: shadowed file layers recover when a plugin winner is disabled or
removed, removing a user-level entry resurrects its project-layer shadow,
disabled plugin descriptors no longer block removals, persisted session
adds validate against the session's project layer and broadcast to other
live sessions, and per-session sync failures are logged with context.
Session status entries and read-only management entries now report
redacted config views (envKeys/headerKeys instead of literal env/headers
values); core-internal reconciliation compares full configs via the
connection manager's raw-entry accessor.
OAuth: interactive flows are serialized per credential (concurrent
begins join the in-flight flow instead of clobbering its PKCE/state), a
malformed credential meta sidecar no longer aborts core start, grants
inside the refresh-ahead window refresh immediately while far-future
grants re-arm through a max-length timer, and the service shuts its
timers and flows down with KimiCore/SDKRpcClient close.
* fix(agent-core): route the proactive MCP OAuth refresh through the token transaction
refreshNow ran its /token request with the SDK default fetch, outside the
credential-serializing OAuthTokenTransaction that every other token write
uses; a slower response carrying an older rotating refresh token could
overwrite a newer grant written by a concurrent transport-side refresh.
* fix(agent-core): keep disabled MCP servers out of auth-state classification
The unified mcpServerAuthState dropped the previous enabled short-circuit,
so a disabled oauth-flagged server reported oauth-required — or was even
probed over the network — instead of not-applicable.
* fix(kimi-code-sdk): short-circuit disabled MCP servers in the v2 auth-status classifier
The v2 parity copy of v1's mcpServerAuthState missed the same enabled
guard v1 just regained; a disabled oauth-flagged entry would report
oauth-required (or be probed). The parity suite now pins the disabled
case on both engines.
* fix(kimi-code): refresh the VS Code MCP list with the workspace cwd after mutations
The add/update/remove RPCs return a cwd-less management list, so the
webview broadcast dropped project-layer entries until the next full load;
re-list with the workspace cwd after every mutation instead.
* fix(agent-core): keep SDK token saves matched to the OAuth token transaction
saveTokens stamped obtained_at onto a fresh object before calling
tokenTransaction.save, so it never matched the exact payload the
transaction recorded for a grant fetch; the consume path was dead and
every save re-wrote. Between the fetch and the SDK callback an intervening
clear could then be overwritten — the resurrected grant came back after a
reset. The write callback stamps the durable record instead.
* fix(agent-core): reject ambiguous legacy name-based MCP auth lookups
The legacy begin/reset auth RPCs took the registry's first name match,
silently starting OAuth for one entry of a runtime-name collision while
the locator path refused the same ambiguity; align them on the shared
uniqueness rule and point callers at the locator-addressed variants.
* fix(agent-core): propagate registry errors during live-session MCP sync
resolveMcpRuntimeTarget collapsed every registry failure into "no target":
a project config file that turned malformed mid-session made sync treat a
still-configured server as gone (tearing down the live connection) and
made config-aware reconnects report "no longer configured" instead of the
actionable config error. Absence still resolves to undefined; malformed
config now propagates — per-session sync logs and keeps the entry, and
reconnect surfaces config.invalid.
* fix(agent-core): close the remaining registry-error and ambiguity gaps
The management guard lookup mapped every registry failure to "absent",
so a malformed project config let a persisted session add write a
user-level entry over an unknown state; only not-found is a miss now. And
the name-only connection test now shares the auth paths' uniqueness rule
instead of probing the first match of a runtime-name collision.
* fix(agent-core): probe the enabled MCP entry under a disabled-name collision
The name-only connection test counted enabled matches for its ambiguity
guard but still probed the first registry match, and the file layers list
before plugins. With a disabled file entry shadowing an enabled plugin of
the same runtime name, Test probed the disabled entry instead of the one a
live session would run. Select the sole enabled match, falling back to the
first entry only when every match is disabled so it reports as disabled.
* fix(agent-core): let session-local MCP adds shadow plugin entries
Caller injection shadows every registry source at session start, plugins
included, and reconciliation leaves caller entries untouched; the live
non-persist add path rejected plugin-owned names anyway, so SDK clients
could not apply the same per-session override without a restart. Gate the
plugin-source rejection on persist: session-local adds connect as caller,
while persisted adds stay rejected as user-level writes behind a read-only
owner.
* fix(agent-core): normalize session MCP names before connecting
The persisted store trims server names, but addSessionMcpServer used the
raw name for the live connect and cross-session reconciliation: a padded
name persisted under the trimmed key while the requesting session ran and
reconciled the raw one, and a blank name connected with no identity at
all. Normalize once up front (rejecting blank) so the store write, the
session entry, and reconciliation agree on the same server.
* fix(agent-core,node-sdk): close the collision-selection and probe-freshness gaps
The legacy name-only auth resolver started from the first registry match,
so a disabled file-layer shadow plus an enabled plugin of the same runtime
name was misread as an ambiguity conflict; select the sole enabled match
before judging ambiguity, exactly like the test probe path. On the v2
client, addSessionMcpServer connected the raw name while the store wrote
the trimmed key — normalize once for both, and route the verify-triggered
auth probes through the per-call OAuth service instead of the cached one
whose providers snapshot tokens at construction, so a grant saved after
the first probe is honored.
* fix(agent-core): normalize global MCP mutation names and guard disabled reconnect swaps
The global add/update/remove mutations guarded and reconciled with the raw
server name while the store persisted the trimmed key, so a padded name
left live sessions unreconciled and could slip past the plugin read-only
guard; normalize once before lookup, persistence, and reconciliation. And
a config-carrying reconnect assigned the replacement before the disabled
check fired, leaving a connected entry that reported the disabled config;
reject disabled replacements before mutating, keeping the same error.
* fix(agent-core): skip proactive refresh while an interactive flow owns the credential
refreshNow reset the shared provider's flow state before and after the
token request; when a proactive timer (or a manual refresh) fired while
beginAuthorization was waiting on the browser callback for the same store
key, that wiped the redirect URL, PKCE verifier, and state the in-flight
flow needed — complete() then failed the exchange even though the user
authorized. Refresh now skips when an interactive flow is active for the
credential: the flow delivers fresh tokens on completion, and the 401
transport path is the backstop if it fails.
* fix(agent-core): allow global MCP adds over disabled plugin descriptors
A disabled plugin entry is absent from the runtime target, but the
read-only guard still treated it as the owner, so a user-level fallback
could only exist if it predated the plugin disable. Relax the shared
guard: disabled plugin descriptors never block mutations (disabled
project entries still shadow the user file and keep their rejection).
* fix(node-sdk): close the v2 session-MCP parity gaps
A v2 reconnect with an explicit enabled:false replacement config used
connect()'s upsert semantics — closing the live client and reporting
success where v1's manager reconnect rejects before applying anything;
reject disabled replacements up front with the same error. And a persisted
v2 session add never consulted the workspace config, so a same-named
project-layer entry was silently shadowed: the user-level write never
takes effect while the direct workspace-manager upsert displaces the
project config for every live session. Resolve the workspace layers and
reject like v1's read-only rule.
* fix(agent-core): keep __proto__-named MCP servers through config parsing
A z.record() parse rebuilds its output via property assignment, so a
server literally named __proto__ hit the prototype setter and vanished
before validation; the layer merge then repeated the same trap with plain
object accumulators. Parse the server map entry-by-entry over the JSON own
keys and accumulate into null-prototype maps, so session startup and the
unified registry keep the declared server and its origin.
* fix(node-sdk): begin v2 MCP auth against a fresh OAuth service
The v2 begin path ran through the cached globalMcpOAuth, whose providers
snapshot tokens at construction: a grant another process saved (or reset)
after that cache materialized was invisible, so begin could open a browser
flow over a valid grant, or report already-authorized off a removed one.
Build the service per call — the read path and the verify probes already
do — and route the status list through the same helper. The test fixture
grows a real token endpoint honoring one rotating refresh token; the
regression fails against the cached-service implementation on v2.
* fix(agent-core): broadcast SDK-driven MCP token invalidations to live sessions
* test(agent-core-v2): give the no-op reconnect test runtime plumbing
The branch added the case against a bare McpConnectionManager, but #2961
made stdio connects resolve the runtime through runtimeResolver, matching
every other case in the file.
The extension now runs on the agent-core-v2 engine by default. The
interface, sessions, and workflows do not change. Two rollback paths
exist, and one function makes the decision
(config/vscode-settings.ts):
- the kimi.useAgentCoreV1 setting (temporary; a window reload applies
the change);
- the KIMI_CODE_LEGACY_FLAG environment variable, which wins over the
setting and has the same semantics as in the CLI.
An engine startup failure shows an explicit error that names the
rollback setting. There is no silent fallback. CI runs the extension
test suite on both engines: the sharded run covers the default v2
engine, and a new test-vscode-legacy job reruns the suite with
KIMI_CODE_LEGACY_FLAG=1.
To keep the v2 path identical to v1 for every method the extension
uses, this change also completes the v2-backed SDK client and the v2
engine:
- Implement session deletion in the v2 SDK client.
- Implement fork truncation at a turn index in the v2 engine, with the
same rules as v1, and reject a fork while the source session has an
active turn.
- Stop the session-level /init run when the turn is cancelled, as v1
does.
- Read session metadata without the archived field as not-archived, so
sessions written by the v1 engine open correctly.
The SDK parity suite now covers session deletion, cancel, and fork
truncation. The known-difference list for the methods the extension
uses is empty.
* refactor(oauth): make X-Msh-Platform an explicit host identity field
X-Msh-Platform was hardcoded to kimi_code_cli in createKimiDeviceHeaders,
so non-CLI hosts could not state their own platform and the desktop had
to patch the header after the fact. KimiHostIdentity now carries a
required platform (every host declares its own value; the CLI constant
stays the fallback only for direct createKimiDeviceHeaders callers), and
userAgentProduct is renamed to productName so the transport identity
uses one name everywhere.
All in-repo identity constructions pass platform explicitly; the wire
value for CLI and VS Code hosts is unchanged (kimi_code_cli).
* feat(agent-core-v2): carry the host identity in the bootstrap snapshot
Replace the flat clientVersion field with a required clientIdentity
(KimiHostIdentity) so every consumer reads the same host identity
object: OAuthToolkitService now passes it to the OAuth toolkit, which
means the OAuth device-flow endpoints (device authorization, token
polling, refresh) on the kap-server path finally send the full X-Msh-*
device headers instead of none, and the telemetry cloud appender reads
client_version from the same source. A built-in CLI fallback keeps bare
bootstrap() calls in tests working; composition roots must pass their
own identity.
The session export manifest grows an optional desktopVersion field
(payload plumbed through; filled by kap-server in a follow-up).
* feat(agent-core): thread the host identity into the managed auth facades
The v1 managed auth facade constructed its OAuth toolkit without an
identity, so token refreshes from inside the core went out without any
X-Msh-* device headers. createManagedAuthFacade now takes an optional
KimiHostIdentity and every call site supplies one:
CoreProcessService._defaultOAuthTokenResolver forwards the core
process's options.identity (the same source _defaultKimiRequestHeaders
uses), and the DI-held services (oauth / auth summary / model catalog)
read it from a new optional identity field on IEnvironmentService. The
library-level "no identity, no device headers" contract is unchanged.
* feat(kap-server)!: require the host identity and derive request headers from it
ServerStartOptions.hostIdentity is now a required ServerHostIdentity
(KimiHostIdentity + optional prompt display fields), replacing both the
old optional HostIdentityOverrides (renamed to PromptIdentityOverrides,
its productName field now displayName) and the version option (renamed
to serverVersion — it is the engine version reported as server_version,
while the host product version travels in hostIdentity.version).
The server now feeds bootstrap's clientIdentity from hostIdentity and
derives the default outbound headers (User-Agent + X-Msh-*) from it via
createKimiDefaultHeaders, so kap-server-hosted OAuth flows and model /
WebSearch requests carry the real host identity instead of a hardcoded
kimi-code-cli fallback UA. Explicit header seeds still win as an escape
hatch.
Session export manifests record the host product version: kimiCodeVersion
now carries hostIdentity.version (the engine version no longer appears),
and desktop exports (desktop: true) are additionally stamped with a
desktopVersion field. The instance registry keeps its host_version wire
field for compatibility (kimi-inspect reads it); only the in-memory name
changed to serverVersion.
* feat(cli): wire the CLI host identity into the kimi web server
kimi web now passes createKimiCodeHostIdentity(version) as the server's
hostIdentity, so web-UI OAuth flows and the engine's outbound requests
carry the explicit CLI identity (productName + version + platform). The
explicit hostRequestHeadersSeed is dropped — kap-server derives the same
headers from hostIdentity — and buildKimiDefaultHeaders goes away with
its only consumer.
* test(klient): drop clientVersion from the bootstrap contract parity list
* chore: add changesets for the host identity unification
* feat(cli): tag kimi web requests with a (web) User-Agent suffix
kimi web shares the CLI product token and platform, so its outbound
requests were indistinguishable from direct CLI runs upstream. Its host
identity now carries userAgentSuffix 'web', putting web-UI traffic at
kimi-code-cli/<version> (web) while X-Msh-Platform stays kimi_code_cli.
* fix(klient): keep the env() clientVersion wire field after the bootstrap identity switch
The bootstrap snapshot replaced the flat clientVersion scalar with
clientIdentity, which broke klient's env() fan-out (RPCError: method not
found). The wire surface keeps clientVersion — now sourced from
clientIdentity.version — and bootstrapService gains a clientIdentity
read (registered in envContract with an object schema) for consumers
that want the full identity.
* feat(oauth): send the product User-Agent on OAuth requests
The OAuth endpoints used to receive only the X-Msh-* device headers
(undici's default UA otherwise), which left the OAuth host unable to
distinguish runtime surfaces — notably kimi web, whose platform matches
the CLI and whose only distinguishing mark is the (web) UA suffix. The
toolkit now feeds the full identity headers (User-Agent + X-Msh-*) into
every device authorization, token polling, and refresh request; the
request-header type widens from DeviceHeaders to OAuthRequestHeaders.
* feat(vscode): report kimi_code_vscode as the extension's platform
The VS Code extension inherited the CLI's hardcoded X-Msh-Platform value;
with platform now an explicit identity field it declares its own, so the
managed endpoints and OAuth host can tell extension traffic apart from
CLI runs.
* refactor(agent-core-v2)!: require the client identity at the composition root
The bootstrap fallback identity fabricated a kimi-code-cli/unknown host
for any caller that forgot to pass one — the same silent-misreport
pattern this series set out to remove, and it made "required" a lie.
BootstrapInput.clientIdentity is now required, so a missing identity
fails at compile time instead of being papered over. Test and example
callers pass a shared fixture (klient examples and test engines get one
each); the node-sdk v2 client asserts its host identity with the oauth
helper. Also folds DeviceHeaders from an interface into a type alias so
it stays assignable to the widened OAuthRequestHeaders record.
* feat(oauth)!: require and validate the platform in device headers
Drops the quiet CLI fallback in createKimiDeviceHeaders (the same
silent-misreport pattern removed from the bootstrap identity): platform
is now a required option, validated with the same required-ASCII rule as
the version — empty or all-non-ASCII values throw instead of emitting a
blank X-Msh-Platform, and header-unsafe characters are stripped rather
than sent raw.
* fix(node-sdk): seed the host request headers on the v2 client path
The interactive v2 engine path (experimental flag) bootstrapped without
a hostRequestHeaders seed, so managed vendor calls went out with the
SDK's default User-Agent (OpenAI/JS) and no X-Msh-* at all — v1 passes
the full identity headers on the same requests. The v2 client now seeds
the headers from its asserted host identity, and a test pins the seed.
* chore: simplify the CLI changeset wording
Chat components subscribed to the entire chat store, so every
streaming delta re-rendered every assistant message. Subscribe to
narrow store slices and memoize ChatMessage so settled messages no
longer re-render on each delta. Cap getImageDataUri at 10MB, matching
the media picker, so oversized local images are not inlined into the
webview DOM.
* fix(tui): correct YOLO and Auto permission mode descriptions
* fix: unify YOLO and Auto permission mode descriptions across CLI, ACP, web, and docs
* docs: correct YOLO and Auto mode descriptions in the interaction guide
* fix: correct YOLO mode notices in session replay and vscode extension
* feat(vscode): rename /afk command to /auto, keeping afk as hidden alias
Also correct the stale 'afk' mode reference in the built-in MCP config
skill guidance of both agent engines.
* fix(vscode): forward engine approval requests instead of blanket-approving them
The extension-level approval handler auto-approved every request when
legacy yolo/afk was on, silently swallowing the sensitive-file,
plan-review, and ask-rule prompts the engine yolo mode still sends.
Forward every request to the user and let the engine permission mode do
the auto-approving, matching TUI and web behavior.
* fix(vscode): stop mid-turn core errors from corrupting the active turn
* fix(vscode): reject prompts during exclusive operations with a terminal error
* chore(vscode): release 0.6.1
* test(vscode): read the extension version from the manifest in version assertions
* test(vscode): declare version on the runtime rig type
* fix(vscode): count configured provider credentials as signed in and make the gear sign-in actually log in
* fix(vscode): keep the gear auth action scoped to the Kimi account session
* feat(vscode): migrate extension to Node SDK
* fix(vscode): address CI failures
* fix(vis): handle token count records
* fix(vscode): keep chat toolbar and header readable at narrow widths
* fix(vscode): map yolo to core yolo permission and honor the global yolo setting
* docs(vscode): record Node SDK migration design
* docs(vscode): split breaking changes out of the 0.6.0 changelog
* fix(vscode): keep a resumed session's thinking effort instead of reapplying the default
* fix(vscode): announce session status when a view attaches so the display matches it
* fix(vscode): align webview thinking effort handling with the TUI
