Tool output from llama-server /props poisons the session permanently (media marker leak)

[palavrov]

Setup: dsh 0.1.1-rc.2 → llama.cpp llama-server (build 74a7c89, 2026-09-05, Vulkan) serving Qwen3.8-27B with --mmproj for vision.

What happens

During a session, the agent ran a diagnostic tool call against the server (curl http://127.0.0.1:9931/props). From that point on, every request in the session failed:

E mtmd_tokenize: error: number of media markers in text (1) exceeds number of bitmaps (0)

and the client gets 400 {"error":{"code":400,"message":"Failed to tokenize prompt"}}. The session is unrecoverable — the offending text is in the history and gets replayed on every turn. A new session works until it hits the same thing.

Why

Since llama.cpp #21962 (April 2026) the multimodal media marker is randomized per server start, and since #22028 GET /props returns it verbatim (media_marker). Any tool output that quotes /props therefore injects the marker into the prompt with no image attached, and mtmd_tokenize hard-fails.

Upstream's position is that this is the client's responsibility: issue ggml-org/llama.cpp#27249 was closed and the fix PR ggml-org/llama.cpp#27375 ("treat unmatched media markers as literal text") was rejected by the maintainer on the grounds that /props also returns the chat template, so feeding it to a model is broken regardless. ggml-org/llama.cpp#25285 remains open for the same failure.

Ask

dsh currently has no filtering between tool output and model context. Two possible mitigations on the dsh side:

1. In the llama.cpp-compatible provider path, strip the media_marker / media_tag field (and ideally chat_template) from any tool result that looks like /props output.
2. More generally: when a turn fails with a tokenize error, surface which message in history contains the offending text, instead of failing every subsequent turn silently. Related failure class: Bug + tested fix: truncated tool-call arguments permanently poison a session (llm-deepseek serializer) #1519 (truncated tool-call args poisoning a session).

Happy to test a fix against this setup.