Stale tool results: new tool calls replay prior call's verbatim result (positional per-name recall)

[MSB0095]

Observed live in TUI session 2026-08-11 01:15-01:25 UTC, jcode v0.75.0 (5ae2385), branch master, cwd ~/.jcode/source/jcode.

Symptom

New tool calls intermittently return the verbatim previous result of an earlier call (including the old [tool timing: start=... finish=...] header). This makes e.g. bash cat file right after edit file show pre-edit content.

Minimal repro sequence from the session:

1. bash: cat > /tmp/stale_test.txt << EOF\nline1 original\nEOF → fresh (call it R1)
2. edit /tmp/stale_test.txt → success, shows updated line
3. bash: cat /tmp/stale_test.txt → returns R1 verbatim (same timing header as Add auto-update system for release builds #1). read in the same batch returned the fresh file correctly.

Evidence that it is a dispatch-layer positional replay (not model/provider cache)

A "punch" batch of 5 parallel identical-name bash probes echo punch-N $(date +%s) returned:

• slot1 → R1 (stale)
• slots2-5 → fresh punch2..punch5

Then a different batch of 5 parallel bash greps (q1..q5, all distinct commands) returned [R1, punch2, punch3, punch4, punch5] — a strict positional 1:1 mapping onto the previous bash batch's results, two turns stale.

Same pattern for agentgrep: a grep "cache_control" + grep find batch both returned the first grep's result (same timing 01:17:04.343). A later read .git/HEAD returned the earlier read Cargo.toml payload (same timing 01:18:09.934). side_panel write with a corrected page_id re-returned the earlier page_id is required for write error verbatim.

Pattern

• Replay is per tool name, keyed by ordinal call position within the batch, persisting across model turns.
• When the previous same-tool batch had N results, a later M-call batch replays positions 0..min(N,M); positions beyond N came back fresh in the same batch.
• Errors replay identically, so the store captures fully-rendered result objects, not just stdout.
• edit, write, todo, debug_socket, mcp__github__* appeared fresh throughout — so the bug is in how built-in parallel tool results are stored/retrieved, not in the whole pipeline.

Where to look

Per-name per-positional result buffer (Vec keyed by call index?) that is not cleared or not fully overwritten when the next turn's batch for that tool is smaller, or a "reuse result" fast-path keyed by (name, position) instead of tool_use id. Suspicious areas: tool dispatch batching in crates/jcode-agent-runtime, result assembly into API messages, and any memoization around tool_result_tag / BatchSubResult (crates/jcode-message-types, crates/jcode-tui/ui_tools/batch.rs).

Full chronological table is in STALE_BUG_EVIDENCE.md at the repo root of the session working copy.

Environment

• OS: linux x86_64, HP i7-1165G7, 7.4 GiB
• Shared-server build channel was the active daemon.

[MSB0095]

Update from live debugging inside the session: the session journal on disk is CORRECT. Every tool call that appeared "stale" in the agent's view is recorded with its fresh payload in ~/.jcode/sessions/session_<id>.journal.jsonl:

• bash:0 at 01:16:39 recorded "line1 UPDATED marker-12345 ... line2 from-bash-1786410999" (fresh) — the agent received the first bash call's output instead.
• read:0 of .git/HEAD recorded "ref: refs/heads/master" — the agent received the earlier Cargo.toml content.
• side_panel:0 with page_id recorded success — the agent received the earlier "page_id is required" error.
• agentgrep:0 with query cache_control recorded 355 matches incl. jcode-app-core/src/agent/** — the agent received the first grep's result.

So execution + persistence are fine. The bug is in the result path from journal back to the model/UI.

Root-cause direction: tool_use ids in this session serialize as "{tool_name}:{ordinal_in_batch}" (bash:0, bash:1, read:1, edit:0...). These collide across every turn that issues a same-named call in the same position. Any cache/map in the result-return path (provider message cache, pending-tools map, UI result store) keyed by that id will serve the first-seen payload for id bash:0 for the rest of the session — which is exactly the observed behavior, including:

• the 1:1 positional mapping when batch sizes match (q_i got punch_i),
• slots beyond the previous batch's size coming back fresh (no id collision yet),
• errors replaying too (cache stores rendered result objects, not stdout).

The provider here was openai-compatible (moonshotai/kimi-k3-free); whether the collision bite is in jcode's own pending-result map or in the provider-side conversation cache, the fix on jcode's side is the same: make tool_use ids globally unique per session (e.g. include a per-turn counter or the journal message id) instead of {name}:{index}, or flush any id-keyed result cache at turn boundaries. The session above (session_cricket_1786410876501_7788b163bc03966c.journal.jsonl) is a ready-made repro trace showing identical ids being reused ~19 times across turns.

Evidence log: STALE_BUG_EVIDENCE.md at repo root of the session's working copy.

[MSB0095]

Correction/narrowing of my earlier comment — the journal shows the collision is in the tool_use IDs sent to the provider, not only in jcode's own maps:

Every assistant.tool_use block in the journal has id: "{name}:{index_in_message}" (bash:0, edit:0, read:1, read:0, …). These recur every time a new model turn issues a call under the same name at the same position. On providers with conversation/prompt caching (this session: openai-compatible / moonshotai kimi-k3-free), the provider appears to key its cached tool result by that id + prefix, and returns the cached (stale) tool_result block — with jcode's own rendered [tool timing: …] payload embedded — to the next turn that reuses the same id. Tools still execute on disk; only the payload handed back to the model and TUI is replaced.

Concrete live proof from the same session:

• read:0 issued for .git/HEAD → agent received the earlier read:0 (Cargo.toml) payload; journal recorded the fresh .git/HEAD result.
• bash:0 issued for echo punch-1 $(date +%s) in a 5-call batch → got the very first bash:0 result; bash:1..4 (punch-2..5) were fresh because those ids had never been used before.
• todo:0 and write:0 were fresh on first use, then a later side_panel:0 write replayed the earlier side_panel:0 error verbatim.

Fix: stop deriving tool_use ids from {name}:{index}. Generate a session-unique id per tool call (e.g. toolu_<nanos>_<counter> like the journal's message ids, or uuid v4), and sanitize only for transport if a provider requires [A-Za-z0-9_-]. The current sanitize_tool_id is a passthrough for toolu_… ids (see crates/jcode-base/src/message/tests.rs::sanitize_tool_id_alphanumeric_passthrough), so a toolu_* scheme is already compatible with existing validation.

Where the id is synthesized: look for where format!("{}:{}", name, index) (or equivalent) builds ToolCall.id when the provider response lacks one — likely in the OpenAI-compatible adapter / message conversion path, not the core loop.

[1jehuang]

I traced this to positional fallback IDs such as bash:0 being accepted unchanged at the OpenRouter-compatible provider boundary. PR #890 replaces only those synthesized fallbacks with unique toolu_ IDs, preserves genuine provider IDs, and adds a two-response regression test. All 27 provider tests pass.

---

— Jcode agent (automated triage), on behalf of @1jehuang

[1jehuang]

The provider-boundary regression passes, but I cannot deterministically reproduce Moonshot's provider-side cache behavior locally. If you can test PR #890 against the original session/provider flow, confirmation that repeated same-position tool calls no longer replay stale results would close the live acceptance gap.

---

— Jcode agent (automated triage), on behalf of @1jehuang