Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
ollama 0.33.3: tool-call requests that don't match the PEG grammar are cancelled with no finish_reason
Reported by Lomare · filed Sep 30, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
ollama 0.33.3: tool-call requests that don't match the PEG grammar are cancelled with no finish_reason
Environment
- Package:
ollama 0.33.3-1(+ollama-rocm 0.33.3-1) from the[omarchy]stable repo (pkgs.omarchy.org/stable) - Hardware: AMD RX 7900 XTX (ROCm)
- Model:
gpt-oss-20b:q4 - Client: any OpenAI-compatible
/v1/chat/completionsconsumer (reproduced with Hermes Agent)
Symptom
When a chat request with tools produces tool-call output that the peg-native PEG parser does not recognize, the server:
- logs
unparsed peg-native output - logs
srv stop: cancel task - closes the SSE stream with no `finish_reason` and no content
The client therefore sees a stream that simply ends mid-request. Consequence for OpenAI-compatible clients: the missing finish_reason is classified as a truncated/partial response, triggering continuation retries that eventually crash the worker.
Root cause (from binary string analysis)
The peg-native grammar expects tool calls framed as:
<|channel|>(commentary|analysis) to=functions<|message|>{ ... }but gpt-oss-20b emits:
<|channel|>functions.<name><|channel|>commentary json<|message|>{ ... }On the mismatch, common_chat_peg_parse fails and the task is cancelled instead of the content (or a finish_reason) being returned. Notably, gpt-oss is not in the fork's known-grammar family (cogito, gemma4, qwen3.5, olmo3, glm-4.6, cohere, lfm2, deepseek, peg-simple, peg-gemma4, peg-minimax-m3), so it falls through to peg-native and fails.
Why this matters
A PEG parse failure should not silently kill the request. For a model the distro ships, the tool-calling path is unusable. This also affects any model whose tool framing doesn't match a known grammar.
Requested fix
On PEG parse failure, one of:
- (a) pass the raw tool-call content through to the client (best-effort), or
- (b) emit a finish_reason (stop or tool_calls) with the content,
rather than cancelling the task and closing the stream with no finish_reason.
Reproduction
POST /v1/chat/completions with gpt-oss-20b:q4, stream: true, and a tools array. Prompt the model to call a tool (e.g. a terminal tool). The stream ends with no finish_reason and no content; the server log shows unparsed peg-native output + cancel task.
View raw text
# ollama 0.33.3: tool-call requests that don't match the PEG grammar are cancelled with no `finish_reason`
## Environment
- Package: `ollama 0.33.3-1` (+ `ollama-rocm 0.33.3-1`) from the `[omarchy]` stable repo (`pkgs.omarchy.org/stable`)
- Hardware: AMD RX 7900 XTX (ROCm)
- Model: `gpt-oss-20b:q4`
- Client: any OpenAI-compatible `/v1/chat/completions` consumer (reproduced with Hermes Agent)
## Symptom
When a chat request with `tools` produces tool-call output that the `peg-native` PEG parser does not recognize, the server:
1. logs `unparsed peg-native output`
2. logs `srv stop: cancel task`
3. **closes the SSE stream with no `finish_reason` and no content**
The client therefore sees a stream that simply ends mid-request. Consequence for OpenAI-compatible clients: the missing `finish_reason` is classified as a truncated/partial response, triggering continuation retries that eventually crash the worker.
## Root cause (from binary string analysis)
The `peg-native` grammar expects tool calls framed as:
```
<|channel|>(commentary|analysis) to=functions<|message|>{ ... }
```
but `gpt-oss-20b` emits:
```
<|channel|>functions.<name><|channel|>commentary json<|message|>{ ... }
```
On the mismatch, `common_chat_peg_parse` fails and the task is cancelled instead of the content (or a `finish_reason`) being returned. Notably, `gpt-oss` is not in the fork's known-grammar family (cogito, gemma4, qwen3.5, olmo3, glm-4.6, cohere, lfm2, deepseek, peg-simple, peg-gemma4, peg-minimax-m3), so it falls through to `peg-native` and fails.
## Why this matters
A PEG parse failure should not silently kill the request. For a model the distro ships, the tool-calling path is unusable. This also affects any model whose tool framing doesn't match a known grammar.
## Requested fix
On PEG parse failure, one of:
- **(a)** pass the raw tool-call content through to the client (best-effort), or
- **(b)** emit a `finish_reason` (`stop` or `tool_calls`) with the content,
rather than cancelling the task and closing the stream with no `finish_reason`.
## Reproduction
`POST /v1/chat/completions` with `gpt-oss-20b:q4`, `stream: true`, and a `tools` array. Prompt the model to call a tool (e.g. a `terminal` tool). The stream ends with no `finish_reason` and no content; the server log shows `unparsed peg-native output` + `cancel task`.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 20:16 UTC