* fix: refuse unsupported image formats instead of poisoning sessions Images in formats providers reject (AVIF, HEIC, BMP, TIFF, ICO) used to pass through to the API, and the resulting HTTP 400 repeated on every later turn because the image_url stayed in the session history. Add a single format policy (accepted set: PNG/JPEG/GIF/WebP) enforced at every ingestion point: ReadMediaFile refuses with a per-OS conversion command; MCP tool results, REST uploads, and ACP prompts replace the image with a text notice; and turn.prompt/steer gates as the last-funnel backstop so the SDK/RPC path cannot poison a session either. Accepted MIME aliases (image/jpg, case/whitespace) are forwarded in canonical form, and data URLs carrying MIME parameters can no longer slip past the gate. Remote image URLs pass through (no bytes to inspect). * fix: canonicalize accepted data URLs with MIME parameters The format gate compared only the MIME token when deciding whether to rebuild a data URL, so an accepted image carrying MIME parameters (`data:image/jpeg;charset=utf-8;base64,...`) was forwarded with its original header. The Anthropic provider splits the data URL and exact-matches the full header against its whitelist, so the part still poisoned the session. Rebuild to the byte-exact canonical URL whenever the original differs, covering aliases, case/whitespace, and parameters with one comparison. Addresses review feedback on PR #1536. * fix: parse data URLs case-insensitively in the image format gate An uppercase `;BASE64,` marker is legal (RFC 2045 encoding names are case-insensitive), but the parser required a lowercase match and returned null, so the gate treated the URL as remote and forwarded it: an unsupported image could still land in the session history, and the Anthropic provider's lowercase-only split then threw on every turn. Match the scheme and marker case-insensitively; the canonical rebuild emits the lowercase form. Addresses review feedback on PR #1536. * fix: harden image format handling against mislabeled and legacy images Two more ways an unsupported image could reach the provider are closed: - Bytes, not labels, decide the format. A data-URL image whose declared MIME disagrees with its magic bytes (e.g. AVIF bytes an image search tool labels image/png) is now gated on the sniffed format at every entry point (MCP results, ACP, SDK/RPC prompt, REST inline and file uploads), so a mislabel cannot slip past the gate. - A poisoned image already in the session history no longer kills the session: a server image-format 400 (or kosong's client-side image rejection) now retries once with every media part replaced by a text marker, mirroring the 413 media-degraded recovery. The recovery also fires during compaction, and the transient-retry fallback no longer burns the retry budget on image-format errors before the dedicated recovery can run. * fix: reject remote image URLs ending in an unsupported extension Remote image URLs (MCP resource_link, REST `kind: 'url'`) carry no bytes to sniff, so a link ending in `.avif` (or `.heic`, `.bmp`, `.tiff`, `.ico`) would pass through and be fetched server-side — and rejected. Reject such URLs by their path extension instead (query/fragment ignored, case-insensitive); extensionless or accepted-extension URLs still pass through to the provider and the 400 recovery. * fix: tighten image format handling for parameterized MIMEs and recovery scope Address two review findings on PR #1536: - A declared media type with parameters (e.g. image/jpeg; charset=utf-8) is no longer misread as unsupported: normalizeImageMime now strips parameters, matching the data-URL parser, so an accepted image with parameters is forwarded instead of dropped. - The image-format recovery predicate is narrowed to specific format/data rejection phrases, so a 400 about image count, size, or image-input support no longer triggers a media-stripped resend that would let the model answer blind to the user's images. * fix * fix: scope image format recovery to images and flag remote SVG URLs - The media_type/mime_type recovery match now requires the message to mention an image, so a video/audio media_type rejection surfaces instead of triggering a blind media-stripped resend. - unsupportedImageMimeFromUrl flags .svg URLs as image/svg+xml without touching the shared suffix map (SVG stays text for the file tools), so remote SVG images get the intended notice instead of a provider rejection. Addresses review feedback on PR #1536. * fix: reject remote MCP images by their declared MIME type An MCP resource_link with an extensionless or signed URL gives the extension gate nothing to work with, and convertMCPContentBlock was discarding the declared mimeType — an honestly-declared AVIF/HEIC link from an image search tool still became an image_url and poisoned the session. Reject on the declared MIME when the server provides one: unsupported declarations become a text notice that keeps the URL so the model can fetch and convert it; accepted declarations pass through as before. Addresses review feedback on PR #1536. * fix: keep image format recovery image-specific and preserve dropped URLs in notices - Drop the bare `media` alternative from the image-format recovery patterns so audio/video media rejections ("unsupported media type", "invalid media type") can never be misclassified as image errors and blindly media-stripped; every pattern now mentions "image" literally. - Remote image URLs rejected by their extension now keep the URL in the replacement notice (gateImageFormatParts and the REST url path), so the model can still fetch and convert the image — matching the declared-MIME resource_link path. Addresses review feedback on PR #1536. * fix: drop malformed data URLs at ingestion instead of letting them poison the session A `data:` URL that fails to parse (missing `;base64,` separator, empty MIME, …) was treated like a remote URL and passed through the format gate; the provider then rejects it on every turn, and the read-side media-stripped recovery keeps paying that round-trip until compaction. Detect unparseable `data:` URLs in gateImageFormatParts and replace them with a (truncated) notice at ingestion, covering the MCP/ACP/SDK/turn paths that share the gate. Addresses review feedback on PR #1536. |
||
|---|---|---|
| .. | ||
| scratch | ||
| src | ||
| test | ||
| AGENTS.md | ||
| CHANGELOG.md | ||
| package.json | ||
| README.md | ||
| SECURITY.md | ||
| tsconfig.json | ||
| tsdown.config.ts | ||
| vitest.config.ts | ||
@moonshot-ai/server
Local REST + WebSocket server that exposes the Kimi Code SDK over a stable wire
protocol. It hosts agent-core sessions and serves them under a single
/api/v1 prefix. This package is private — it is not published on its own;
it ships inside the kimi CLI (apps/kimi-code) and is launched via
kimi server run.
What it does
- Hosts
agent-coresessions, prompts, tools, approvals, questions, and workspaces in process. - Exposes them over REST (Fastify) and WebSocket (
ws) under/api/v1. - Serves the built-in web UI (
apps/kimi-web) as static assets when awebAssetsDiris provided. - Publishes machine-readable contract docs:
/openapi.json,/asyncapi.json.
Running it
# From the repo root — dev server with auto-restart
pnpm dev:server
pnpm dev:server:restart
# Checks
pnpm --filter @moonshot-ai/server typecheck # tsc --noEmit
pnpm --filter @moonshot-ai/server test # vitest run
pnpm --filter @moonshot-ai/server build # tsdown
The public entry point is startServer(opts) in src/start.ts, which returns a
RunningServer. In production the CLI command kimi server run
(apps/kimi-code/src/cli/sub/server/run.ts) imports and calls it. This package
has no dev script of its own — always start it from the repo root or via the
CLI.
By default the server listens on 127.0.0.1:58627; e2e clients target it with
KIMI_SERVER_URL (default http://127.0.0.1:58627).
Architecture
apps/kimi-code (CLI) apps/kimi-web (browser)
│ │
└──────────┬───────────────────┘
│ REST + WebSocket, /api/v1
┌──────────▼───────────┐
│ @moonshot-ai/server │
│ Fastify REST │
│ ws gateway │
│ DI container │ ← @moonshot-ai/agent-core
│ agent-core sessions │ ← @moonshot-ai/agent-core
└──────────────────────┘
- REST (
src/routes/): domain modules aggregated byregisterApiV1Routes.ts. Routes are declared withmiddleware/defineRoute.ts, which bundles Zod validators with the OpenAPI response schema. - WebSocket (
src/ws/,src/services/gateway/): per-sessionseq,server_hello/ack/event/resync_requiredframes, replay and fan-out. - DI (
src/services/serviceCollection.ts): seeds the container from@moonshot-ai/agent-core(getSingletonServiceDescriptors()) and layers in server-owned gateways plusIApprovalService/IQuestionServiceimplementations. - OS service managers (
src/svc/): launchd / systemd / schtasks backends forkimi server install/start.
Wire protocol notes
- Envelope: every REST response is
{ code, msg, data, request_id }and the HTTP status is effectively always 200 — checkcode(0 = ok), not the status. :actionendpoints: some routes use an:id:actionsuffix (e.g./sessions/{id}:undo); the suffix is parsed byroutes/action-suffix.ts.- Single-instance lock: a running server acquires a lock; a second start on
the same home throws
ServerLockedError. Tests pass a uniquelockPath/port.
Related packages
@moonshot-ai/agent-core— the agent engine the server hosts, including the in-process DI service layer it wires together.@moonshot-ai/protocol— wire types and the AsyncAPI document.@moonshot-ai/node-sdk— typed in-process facade for user code (KimiHarness,Session); prefer it over hand-rolling REST/WS calls.@moonshot-ai/server-e2e— wire-level e2e client and scenarios against a running server.
Development
For conventions, gotchas, and the boot wiring order, see
packages/server/AGENTS.md. For the service naming and
registration rules, see
packages/services/AGENTS.md.