Summary
The CLI and Web agent loops cannot recover when the real DeepSeek model emits an unwrapped tool call such as run_cmd: instead of the documented Action: JSON block. The bounded retry loop exhausts and blocks the remaining work without a useful protocol diagnosis.
Environment
- Repository:
EvanProgramming/OpenKyrozen
- Commit:
bb46869f09f8b42dbe65cf5c39009ac5f3a50a0b
- macOS arm64, Python 3.12
- Fresh GitHub clone, isolated HOME, SQLite database, and disposable projects
- Provider: DeepSeek, model
deepseek-v4-flash
- No credential, private path, or private memory content is included here
Reproduction
- Launch the documented CLI or Web entry point with the model selections set to
deepseek-v4-flash.
- Submit a normal request that requires inspect, edit, test, and Git steps.
- Observe the model's later tool turns and the bounded recovery result.
In multiple real DeepSeek runs, initial canonical actions (list_dir, read_file) succeeded, then the model emitted markdown/pseudo-action text using run_cmd: and code-fenced command descriptions. The current collector did not turn those into tool calls. After 12 unsuccessful nudges, OpenKyrozen reported that the remaining tasks were blocked; the requested edit/verification/commit did not complete.
Expected
The agent should either safely normalize an unambiguous provider alias into a canonical tool call or stop promptly with an explicit protocol-format error and actionable recovery. It should not silently replay the same prompt until the user receives a blocked plan for a routine task.
Actual
_collect_tool_calls recognizes the documented Action: forms and JSON objects but not the observed run_cmd: pseudo-action syntax. The retry loop repeats without producing progress, while the Web stream can expose the malformed control text (see the separate streaming issue).
Impact
Normal DeepSeek users can get no-op/retry loops and blocked plans even after earlier tools succeeded. This makes task execution unreliable and prevents meaningful Git/project work through both supported surfaces.
Acceptance criteria
- Define and test a safe compatibility policy for unwrapped/alias tool syntax from the supported DeepSeek model, or emit a direct protocol error with no repeated blind retries.
- Never execute an ambiguous or malformed call; preserve authorization, argument, duplicate-operation, and destructive-action gates.
- Bound retries with a clear user-facing explanation that identifies the malformed response and the blocked items.
- Add CLI and Web integration tests covering canonical, alias, split, malformed, and prose-mixed model output.
Summary
The CLI and Web agent loops cannot recover when the real DeepSeek model emits an unwrapped tool call such as
run_cmd:instead of the documentedAction:JSON block. The bounded retry loop exhausts and blocks the remaining work without a useful protocol diagnosis.Environment
EvanProgramming/OpenKyrozenbb46869f09f8b42dbe65cf5c39009ac5f3a50a0bdeepseek-v4-flashReproduction
deepseek-v4-flash.In multiple real DeepSeek runs, initial canonical actions (
list_dir,read_file) succeeded, then the model emitted markdown/pseudo-action text usingrun_cmd:and code-fenced command descriptions. The current collector did not turn those into tool calls. After 12 unsuccessful nudges, OpenKyrozen reported that the remaining tasks were blocked; the requested edit/verification/commit did not complete.Expected
The agent should either safely normalize an unambiguous provider alias into a canonical tool call or stop promptly with an explicit protocol-format error and actionable recovery. It should not silently replay the same prompt until the user receives a blocked plan for a routine task.
Actual
_collect_tool_callsrecognizes the documentedAction:forms and JSON objects but not the observedrun_cmd:pseudo-action syntax. The retry loop repeats without producing progress, while the Web stream can expose the malformed control text (see the separate streaming issue).Impact
Normal DeepSeek users can get no-op/retry loops and blocked plans even after earlier tools succeeded. This makes task execution unreliable and prevents meaningful Git/project work through both supported surfaces.
Acceptance criteria