Model emits Read tool calls instead of Write/Edit — text says 'calling Write', wire shows Read (0.39.1, k3-256k)

What version of Kimi Code CLI is running?

0.39.1 (homebrew, /opt/homebrew/bin/kimi)

Which open platform/subscription were you using?

Kimi Code subscription (managed kimi-code provider, OAuth login via api.kimi.com)

Which model were you using?

kimi-code/k3-256k (shown as K3-256k, thinking effort high)

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS, Apple Silicon)

What issue are you seeing?

In one session, every attempt to call the Write or Edit tool arrived at the tool layer as a Read call with the same path argument — 5/5 Write attempts and 1/1 Edit attempt. The file was never created/modified. The assistant's own text in the very same message said it was calling Write/Edit.

I first suspected the harness was downgrading/remapping the calls (read-only mode, permission deny). The session wire file (wire.jsonl) proves that is NOT the case — the model itself emitted Read as the tool name, and the CLI faithfully executed what it received:

1. Permission mode is yolo — no read-only/plan restriction:

   {"type":"permission.set_mode","agentId":"main","mode":"yolo"}
   

2. The tools payload sent to the API (201 tools, llm.tools_snapshot) does contain the Write and Edit definitions — the model had them available.
3. Counting actual tool calls in the wire: "name": "Write" appears 0 times, "name": "Edit" 0 times. All write attempts are recorded as e.g.:

   CALL: Read | {'path': '/tmp/kimi-tool-test/hello.txt'}
   CALL: Read | {'path': '/tmp/kimi-tool-test/write-test.txt'}
   CALL: Read | {'path': '/tmp/kimi-tool-test/edit-test.txt'}
   

   i.e. the arguments were generated correctly for a write (right path), but the tool-name token came out Read.
4. The assistant message pairs contradictory text and tool call, e.g. text 现在实际调用 Write。 ("now actually calling Write") immediately followed by a Read tool call on that path.
5. A control Bash file write (printf > file) in the same session worked fine, so disk/permissions are not the issue.

What steps can reproduce the bug?

1. Start a session on model kimi-code/k3-256k.
2. Ask: "试一下edit和write能不能正常调用" (test whether Edit and Write work).
3. The agent attempts Write to a new path → executes as Read → "file does not exist" → retry loop, never actually writing.

Session id: session_82ba1b98-f6a8-4b16-8e5a-e8fc5f52e539 (workspace claudecode-workspace, 2026-08-30 15:24 UTC).

Reproducibility unknown — likely intermittent/model-side. I have not yet retried in a fresh session.

What is the expected behavior?

When the model decides to call Write/Edit (its own reasoning text says so), the emitted tool call should carry the matching tool name, so the file actually gets written.

Additional information

• Possibly the same K3 family of "wrong tool around write operations" as #2623 (plan mode loops on Bash echo/ReadFile instead of writing the plan) and #2617 (Edit/Write report success but never write to disk). Ours is a different symptom at a different layer: here the write tool is never invoked at all — the emitted call is Read — which may help isolate whether the root cause is model-side tool-name emission vs. tool execution.
• I can provide the full wire.jsonl (909 KB) and session log privately on request; it contains the complete evidence chain (permission mode, tools snapshot, all emitted tool calls, and the assistant text/call mismatches).

Start with the session wire.jsonl and the llm.tools_snapshot entries described in the report, then trace how emitted tool names reach the tool layer. Compare the model's assistant text with the recorded calls for the Read, Write, and Edit tools; done means the reported reproduction no longer turns Write/Edit attempts into Read calls.