[Bug] Local Ollama models answer injected runtime/skill/time context instead of the user's task, so no tool is ever called (0.2.1-rc.2)

[2357693401-byte]

Summary

With an Ollama (OpenAI-compatible) provider, a simple file-editing request never produces a tool call. Before generation DSH appends three injected context snapshots — runtime-context, skill-catalog, time-context — after the real human message, all with role: "user". Small local models treat the last user message as the current request: gpt-oss:20b explains the timestamp from time-context, qwen3:8b acknowledges the skill catalog. The file is never read or edited.

This is not a sandbox or tool-execution failure: the tools are in the request, toolMs is 0, and the assistant message has no tool-call block.

Environment

DSH	0.2.1-rc.2 (also seen on 0.2.0-rc.2), via dsh web
Ollama	0.35.1, endpoint http://127.0.0.1:11434/v1
Models	gpt-oss:20b (MXFP4), qwen3:8b (Q4_K_M)
Node.js	v24.15.0
OS	Windows 11 (build 26200)
Session	Standard preset, workspace-write

Provider config (excerpt of ~/.dsh/profiles/web/cordis.patch.yml):

- id: llm-pi-ai
  name: "@deepseek-ai/dsh-llm-pi-ai"
  config:
    providers:
      ollama:
        displayName: Ollama Local
        api: openai-completions
        baseURL: http://127.0.0.1:11434/v1
        models:
          - id: qwen3:8b
            name: qwen3:8b
          - id: gpt-oss:20b
            name: gpt-oss:20b
        apiKeyEnv: <redacted>
- id: agent-default-model
  name: "@deepseek-ai/dsh-agent-default-model"
  config:
    provider: ollama
    model: gpt-oss:20b

Same result when launched with ollama launch dsh --model gpt-oss:20b.

Reproduction

1. Configure the Ollama provider above.

2. Create a new session: Standard preset, workspace-write, model gpt-oss:20b.

3. Make sure test.md exists in the workspace.

4. Send (the original request was in Chinese; English translation below it):

   请读取当前工作区中的 test.md。
   
   然后使用文件编辑工具，将 test.md 的全部内容替换为：
   
   DSH + Ollama + GPT-OSS 20B 环境测试成功
   
   必须实际修改文件，不要只告诉我如何修改。
   

   Please read test.md in the current workspace. Then use the file editing tool to replace the entire contents of test.md with "DSH + Ollama + GPT-OSS 20B environment test successful". You must actually modify the file; do not only tell me how to modify it.

5. The model calls no tool and replies about the injected timestamp. test.md is unchanged.

Happens in fresh sessions every time I tried.

Current behavior

Session events for turn 1:

seq	type	source.kind	content (trimmed)
7	system/message		system prompt
8	user/message	user	the human request above
9	user/message	runtime-context	Current runtime context. This snapshot supersedes earlier runtime-context snapshots...
10	user/message	skill-catalog	<system-reminder> A skill is a reusable set of task-specific instructions...
11	user/message	time-context	Time sampled while preparing turn 1, step 1: <timestamp>...
12	request/header		31 tools, including read, edit, write, glob, grep, pwsh, skill
13	request/context
17	assistant/message		reasoning + text only, no tool-call
19	turn/end		reason.kind: "completed"

seq 8–11 all have "role": "user". Example (seq 11, trimmed):

{"type":"user/message","seq":11,"data":{"role":"user","source":{"kind":"time-context","form":"snapshot"},"content":[{"type":"text","text":"Time sampled while preparing turn 1, step 1: <timestamp>..."}]}}

The reasoning at seq 17 shows the model took seq 11 as the user's message:

The user message: "Time sampled while preparing turn 1, step 1: <timestamp> ..."
User didn't ask a question but gave a time stamp. Probably asking to interpret that timestamp?
...
Thus output: "The timestamp corresponds to <utc-time> UTC ..."

The final reply only converts the timestamp to UTC (The timestamp you provided, <timestamp>, denotes the moment of ...), and the turn ends as completed. Session stats: "toolMs": 0, "pendingCalls": {}.

The session title, generated by the same model from the same human message, was correct ("test.md 内容替换" / "replace test.md contents"), so the model understood the request when it was the only message it saw.

Which injected message the model latches onto depends on the model:

• gpt-oss:20b: answers the final time-context snapshot.
• qwen3:8b: I've received the system reminder about the available skills. I'm ready to assist..., or The user hasn't asked a question yet. No action needed.

Expected behavior

The human message (seq 8) is the active task, giving roughly read(test.md) → edit/write(test.md) → final reply. Injected snapshots should not look to the model like a newer user request.

Where the ordering comes from

Checked on master 687f282 (2026-10-17):

• agent-loop/src/agent.ts preStep() returns [...claimed, context], so the runtime-context snapshot goes after the claimed human message.
• runtime-context.ts project() builds that snapshot with createUserMessage.
• time-context/src/index.ts appends another createUserMessage after decision.messages.
• llm-pi-ai/src/context.ts (and L366-L371) sends every remaining harness message as role: 'user' without looking at source.kind.

So source.kind separates injected context from human input inside DSH, but on the OpenAI-compatible route the model just sees four consecutive user messages with the real request first and a timestamp last.

Possible fixes

1. At step start, place injected context before the claimed human message so the request is last (option A in 建议：不要将英文 runtime-context 快照 / 技能目录追加在用户消息之后，避免冲淡"过程叙述"对用户语言的跟随 #4117; same reorder as Pre-step batch places the user prompt before injected context, forfeiting cross-session prefix cache (measured: 42% vs 99.8%) #4749). Pre-step batch places the user prompt before injected context, forfeiting cross-session prefix cache (measured: 42% vs 99.8%) #4749 raised the concern that reordering changes recency/steering — this report shows the current order already steers small models away from the task.
2. Where the route supports it, send these snapshots as system/developer content instead of user.
3. If neither works for a route, frame each snapshot in-text as internal context rather than a request (as suggested in [BUG反馈] AI 对系统提示做出可见回应，打断用户任务流程 #5352).
4. Regression test against a mock OpenAI-compatible endpoint: human request + runtime-context + skill-catalog + time-context, asserting the outgoing request ends with (or clearly marks) the human request.

Tried, did not help

• Switching qwen3:8b → gpt-oss:20b
• Fresh sessions; workspace-write
• dsh web and ollama launch dsh --model gpt-oss:20b
• Updating DSH 0.2.0-rc.2 → 0.2.1-rc.2
• curl.exe http://127.0.0.1:11434/v1/models lists the installed models, so the endpoint itself is fine.
• Disabling time-context with a partial preset-standard profile override failed with agent-preset/not-found: Unknown agent preset: standard (override reverted; no files inside the installed package were edited). If there is a supported way to turn off time-context / skill-catalog per provider, that would be a useful workaround.

Related

• [BUG反馈] AI 对系统提示做出可见回应，打断用户任务流程 #5352 — same behaviour (model answers the last injected user message, the skill catalog, instead of the task), claude-opus-5 on 0.1.1-rc.2
• 建议：不要将英文 runtime-context 快照 / 技能目录追加在用户消息之后，避免冲淡"过程叙述"对用户语言的跟随 #4117 — proposes moving runtime-context / skill catalog before the user message
• Pre-step batch places the user prompt before injected context, forfeiting cross-session prefix cache (measured: 42% vs 99.8%) #4749 — same ordering, from the prompt-cache side
• 配置本地部署的大模型后，普通对话能够正常使用，但是一涉及到修改文件就报错 #4460 — "local model chats fine but fails whenever it should edit files"; possibly the same cause

Attachments

Attached (redacted: username and workspace path replaced with placeholders, time zone removed):

• session-debug-full.redacted.jsonl.txt — the full session log for the turn above (one JSON event per line; .txt added so GitHub accepts the upload)
• critical-events.redacted.txt — the key events (seq 7–13 and 17) pretty-printed
• injection-search.redacted.txt — where runtime-context / skill-catalog / time-context are produced in the installed 0.2.1-rc.2 package

The original session.v4.jsonl.zstd is available if needed.

[argszero]

For anyone hitting this: the ordering can be corrected from a plugin today, with no core change — I built one for this thread.

@argszero/dsh-human-request-last listens on the agent/pre-step waterfall with prepend, so it reads the fully composed batch, and moves every harness-injected user-role message ahead of the human message, keeping each group's own order. In your setup the outgoing request then ends with the actual request instead of the timestamp, which is the thing gpt-oss:20b and qwen3:8b were answering.

Install (npm publication is still pending; the repository carries its compiled output, so a git install runs no build step):

dsh plugin add github:argszero/dsh-human-request-last

Knobs: mode: reorder | report | off — report logs what a deployment would send without rewriting, which is the cheap way to see the ordering on a new route. dropKinds removes an injected snapshot outright, so time-context can be turned off for this provider that way; that is the per-provider workaround your preset-standard override attempt did not reach. runtime-context cannot be dropped: the loop appends its fresh projection even when the placeholder is gone (agent.ts, the contextAdmitted branch), so only its position can move. humanKinds widens what counts as the request for deployments that relay input between agents.

What it guarantees: a batch carrying at least one human message and at least one injected message comes back with the injected messages first and the human messages last, each group in its original order; an unchanged batch is returned as the same object (no copy, no extra token); a step with no human message — a wake or continuation step, where the injections are the input — is left untouched. The rewrite is durable rather than cosmetic, because the loop appends decision.messages in the order returned, so the session log records the corrected order too.

Scope, stated plainly: this is a fix at the batch boundary, not the upstream fix. Moving the runtime snapshot before the claimed input at the source, or sending source-attributed context as system/developer content on routes that support it, remain core changes — #4117 and #4749 hold the design discussion and the prompt-cache trade-off. The plugin exists so Ollama and other OpenAI-compatible deployments are not blocked until one of those lands.