`--model` makes non-interactive runs hang at `user_intake` with zero output (grok CLI 1.0.5)

[bockybocky]

Bug: --model flag makes non-interactive runs hang at user_intake with zero output

Version: grok 1.0.5 (5115b46bc9) [stable]
Platform: Windows 11, git-bash
Auth: logged in with grok.com

Summary

In non-interactive mode, passing --model causes the run to stall at user_intake
and produce no output at all. Removing the flag — with everything else identical —
makes the same prompt complete in ~140s. This reproduces with grok-4.5 and with
grok-4.6, which is the CLI's own default model. Naming the default explicitly breaks
the run; leaving it implicit works.

Reproduction

printf 'Reply with exactly the word PONG and nothing else.' > p.txt

# A — with --model: no output, killed by our timeout
timeout 300 grok --prompt-file p.txt --output-format plain --model grok-4.6 > a.out 2> a.err
# rc=124, a.out is empty, a.err is empty

# B — identical minus --model: works
timeout 300 grok --prompt-file p.txt --output-format plain > b.out 2> b.err
# b.out contains "PONG"

Results (5 runs)

Run	Flags	Outcome
A	--model grok-4.5	no output, stalled 300s
B	(no --model)	PONG in 140s
C	--model grok-4.6 (the default)	no output, stalled 300s
D	--model grok-4.6, no --permission-mode	no output, stalled 220s
E	--permission-mode plan, no --model	PONG

D and E isolate the cause: --permission-mode is not involved. --model alone is
sufficient to reproduce.

What the internal log shows

Polling ~/.grok/logs/unified.jsonl during run A, the last recorded step stays
user_intake for the entire 300s. With --model omitted, the same prompt progresses
user_intake → handle_prompt_user_start → shell.handle_prompt.done within ~140s.
So the run never leaves intake — it is not slow inference, nothing starts at all.

Also worth noting: stderr is empty in the failing case. There is no error, no warning,
no rejection of the model id — the run simply never proceeds.

Impact

Any automation that pins a model is silently dead. Pinning is a common practice for
scheduled jobs and regression harnesses, precisely to detect when a provider changes
models underneath you. In our case a daily model-drift monitor pinned --model and
recorded empty results for 7 days (2026-08-14, 08-15, and 08-17 through 08-21)
before anyone traced it to this flag.

The official Claude Code plugin (xai-org/grok-build-plugin-cc) forwards --model
for /grok-build:delegate and /grok-build:review, so those paths appear affected too.

Secondary issue (may be related, may be separate)

Even in the working case, the process does not exit after writing its answer.
Across 7 runs of a trivial one-word prompt: the answer landed in stdout at 102–131s,
but the process was still alive at our 600s cap in 5 of 7 runs. Of the 2 that did
exit on their own, one returned exit code 1 despite having produced the correct answer.
So neither exit timing nor exit code is a usable completion signal for scripting;
we currently detect completion by watching for shell.handle_prompt.done in
unified.jsonl and then killing the pid.

Expected behavior

--model <id> should either run the requested model, or fail loudly with a clear
error if the id is unavailable. It should not stall indefinitely with no output
and no diagnostic.