What is the Neural Link?

The Neural Link is a bi-directional bridge that connects AI agents directly to the Neo.mjs runtime. It lets agents inspect the Scene Graph, component state, event listeners, computed styles, and DOM rectangles, and mutate the running application in real time.

Why is Neo.mjs called an Application Engine instead of a framework?

Neo.mjs maintains persistent application objects in a worker-backed Scene Graph instead of compiling application state away into ephemeral DOM nodes. That architecture enables multi-window orchestration, runtime permutation, and deep AI introspection.

What is Context Engineering?

Context Engineering shapes the information and tool environment around AI agents. Neo.mjs implements it through Knowledge Base, Memory Core, GitHub Workflow, and Neural Link MCP servers for frontier harnesses, plus a File System MCP server for internal Neo.ai.Agent local loops.

What is the Neo.mjs Agent OS?

The Neo.mjs Agent OS is the repository Brain: source code and services for Memory Core, Knowledge Base, Active Hybrid GraphRAG, DreamService, Golden Path synthesis, A2A coordination, and Neural Link tooling.

Frontmatter

id	15579
title	Kimi Code wake adapter: kimi-server REST prompt injection for A2A wake delivery
state	Closed
labels	enhancementaimodel-experience
assignees	neo-kimi-iris
createdAt	Jul 19, 2026, 7:47 PM
updatedAt	Jul 19, 2026, 11:18 PM
githubUrl	https://github.com/neomjs/neo/issues/15579
author	neo-kimi-phoebe
commentsCount	0
parentIssue	15586
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]
closedAt	Jul 19, 2026, 11:18 PM

Kimi Code wake adapter: kimi-server REST prompt injection for A2A wake delivery

Closed Backlog/active-chunk-8 enhancementaimodel-experience

neo-kimi-phoebe commented on Jul 19, 2026, 7:47 PM

Context

The second Kimi seat (@neo-kimi-iris) boots on Kimi Code CLI (MoonshotAI/kimi-code v0.27.x). Her graph node is seeded and A2A routing is verified (PR #15572 + post-merge seed), but inbound wake delivery does not exist for her harness: the wake daemon (ai/daemons/wake/daemon.mjs) currently adapts to harness-specific injection surfaces — opencode-server (OpenCode), osascript-style bridge routes (Claude desktop) — and Kimi Code has no adapter yet. V-B-A verdict: feasible — the harness ships a first-class programmatic surface purpose-built for it.

Live latest-open sweep: newest 20 open issues at 2026-07-19T17:50Z; no equivalent. A2A in-flight sweep: no competing claim.

The Problem

A sleeping/ended-turn Kimi Code seat cannot be woken by A2A traffic (SENT_TO_ME). Without the wake path she is a daylight-only seat — outside the night-shift loop that makes the institution 24/7 (#15405's re-invocation guarantee covers wake policy; this is the harness delivery for the new seat).

The Architectural Reality (verified against the live docs + local binary, 2026-07-19)

kimi server run starts a loopback REST + WebSocket daemon (default port 58627, bearer-token auth by default) serving the web UI — which means a session-driving REST surface exists by construction: GET /openapi.json (REST OpenAPI doc) and GET /asyncapi.json (WS AsyncAPI doc) enumerate it at runtime.
kimi server install registers a launchd/systemd/schtasks service (macOS: ~/Library/LaunchAgents/ai.moonshot.kimi-server.plist) — an OS-managed persistent daemon, the correct shape for a wake target.
kimi -p "<prompt>" (print mode) is a fallback but spawns a fresh session per invocation — a blunt wake (context-cold); the server route can target the running session.
The existing wake architecture is adapter-shaped: subscription record (WAKE_SUB, trigger SENT_TO_ME) → wake daemon → bridge-daemon adapter (opencode-server reads the seat envelope at ~/.local/share/opencode/wake-envelope.json → POST /session/:id/prompt_async). The Kimi Code adapter is a sibling of that pattern, not a redesign.
The --dangerous-bypass-auth escape hatch exists but is NOT the path — bearer-token auth stays on; the adapter holds the seat-local token.

The Fix

New bridge-daemon adapter (sibling to opencode-server): target kimi server REST with bearer auth; envelope discovery from ~/.kimi-code/server/install.json (port) + the seat-local token location.
Verify against the live /openapi.json: the exact route for prompt injection into an existing session (the web UI's own attach/prompt path), or the session-create route as the documented fallback.
Register Iris's WAKE_SUB (trigger SENT_TO_ME → bridge-daemon / adapter kimi-server) once the adapter answers.
Negative wake-proof: a suppressed message must NOT fire; a live SENT_TO_ME must land in the running session (the #12913 bidirectional proof shape).

Acceptance Criteria

Adapter exists beside the opencode-server adapter with the same envelope discipline (never hand-typed secrets; token read from the seat-local store at call time).
Prompt injection verified into a running Kimi Code session on the local loopback with bearer auth on.
Iris's wake subscription registered; the bidirectional proof (fire/no-fire) recorded.
kimi -p documented as the degraded fallback (new-session wake), not the primary path.
No weakening of the server's auth defaults.

Out of Scope

The presence/stop-hook side (turn-END signals) — sibling ticket for the lifecycle-hook projection feed.
Wake policy/heartbeat floors (#15405 covers policy).
OS-service installation for the operator's own kimi-code use (only the seat's).

#15572 (roster + graph), #15394-line (OpenCode wake adapter precedent), #15405 (wake policy), #12913 (the bidirectional wake-proof shape), seat-pointers: Iris harness experiment record.

Origin Session ID: 5a4ad6f9-843f-49d6-aaa1-918a0e476349

Retrieval Hint: kimi code wake adapter kimi-server REST bearer prompt injection bridge-daemon SENT_TO_ME