Open pstack fail to run grok on a Claude code cloud session

[nirdrang]

It fails due to the sandbox request on a Claude code cloud session .

[mast-factory]

Type	bug — A supported Claude Code parent can reach a non-interactive Grok permission/sandbox path that cannot complete.
Route	Planning
Severity	🟡 medium — Grok can be a complete dropout for the affected Claude Code cloud workflow, but the other model families and local parent profiles remain usable.
Confidence	low — The repository contains two matching headless Grok permission defects, but the report has no command, lane, receipt, Grok version, or exact sandbox message to identify which boundary failed.
Effort	medium — The command fix is likely small; proving it safely requires both access modes and an actual Claude Code cloud harness.
Impact	medium — Users can lose Grok from setup and multi-model runs on a documented Claude Code surface, reducing both coverage and review diversity.
Next step	Reproduce the Claude-cloud launch with the setup read-only probe first, then apply the provider-specific non-interactive permission fix without removing the Grok or parent sandbox.

Understanding

Open Pstack launches Grok as a headless external CLI from Claude Code. The report says that launch fails in a Claude Code cloud session when a sandbox request occurs. The runner cannot answer an interactive request, so any such request is terminal.

Evidence and diagnosis

• plugins/pstack/skills/poteto-mode/scripts/runner/commands.ts:58-60 shares one permission selector between Claude and Grok: plan for read-only and acceptEdits for isolated-write. Grok receives that value at commands.ts:121-146 together with its own read-only/workspace sandbox, a restricted tool list, an assigned cwd, denied recursive tools, and --no-subagents.
• Setup uses a read-only Grok probe. Closed, unmerged PR fix(runner): Grok read-only lanes bypass the permission classifier, and failures name their state #40 documents that Grok treats plan as a no-op, can fall back to an interactive classifier in headless mode, and was measured failing until read-only Grok used bypassPermissions inside the retained read-only sandbox.
• Open issue Grok isolated-write lanes cancel headless edit permissions #34 and draft PR fix(pstack): unblock headless Grok writers #48 cover the complementary write-lane failure: Grok Build 1.0.13 cancels a headless search_replace request under acceptEdits; using bypassPermissions while retaining the workspace sandbox and tool restrictions completed the writer probe.
• plugins/pstack/skills/poteto-mode/references/provider-dispatch.md:72 separately notes that the parent tool sandbox governs child credential and network access. If the cloud sandbox blocks Grok before its model process can run, that is a different boundary and must remain a loud dropout rather than being “fixed” by elevating permissions.
• The current tests encode the problematic arguments: commands.test.ts:85-114 expects read-only Grok plan, and commands.test.ts:116-147 expects isolated-write Grok acceptEdits.
• A live reproduction was not possible in the triage sandbox because it has no grok, claude, or codex executable and is not a Claude Code cloud session. The focused Bun test also could not run because Bun is absent. Static command construction and the independent evidence in fix(runner): Grok read-only lanes bypass the permission classifier, and failures name their state #40 and Grok isolated-write lanes cancel headless edit permissions #34/fix(pstack): unblock headless Grok writers #48 establish a repository path consistent with the report, but not the exact cloud failure.

This is not being closed as a duplicate of #34: #34 proves only a Codex-parent/Linux isolated-write failure, while #56 specifically names Claude Code cloud and does not identify the lane. Planning should consolidate the fixes if the reporter's failure is the same child permission path; otherwise it should preserve #56 as the parent-cloud compatibility case.

Assumptions

• “Sandbox request” means an interactive request encountered while starting or running Grok, not an authentication or unavailable-model error.
• The failure occurs through pstack-runner, most likely during setup's read-only probe or an isolated-write lane.
• No implementation should remove --sandbox, broaden the Grok tool allowlist, or bypass the Claude Code cloud sandbox.

Reproduction

1. In an actual Claude Code cloud session with a signed-in Grok CLI, run setup-pstack's one-turn Grok probe and preserve stderr, the runner receipt, and ~/.grok/sessions sandbox events.
2. Invoke pstack-runner with --parent claude --provider grok in both --mode read-only and --mode isolated-write.
3. For the writer case, use a dedicated worktree and request one search_replace edit.
4. Record whether the request is raised by Claude's parent sandbox, Grok sandbox startup, or Grok's permission classifier. That distinction selects the fix and determines whether Grok isolated-write lanes cancel headless edit permissions #34/fix(pstack): unblock headless Grok writers #48 already owns it.

Acceptance criteria

• A Claude Code cloud run of the Grok read-only setup probe completes headlessly with a valid output and complete receipt, or fails before model launch with an actionable receipt that names the parent-sandbox/authentication boundary.
• A Claude-parent Grok isolated-write probe can use the explicitly allowed search_replace tool without an interactive prompt; consolidate this behavior with Grok isolated-write lanes cancel headless edit permissions #34/fix(pstack): unblock headless Grok writers #48 rather than implementing it twice.
• Grok keeps its assigned cwd, read-only or workspace OS sandbox, mode-specific tool allowlist, denied Agent,search_tool,use_tool, disabled web search, and no-subagent controls.
• Claude's own plan/acceptEdits mapping remains unchanged.
• No failed Grok lane silently falls back to another model or elevated sandbox access.

Test strategy

• Add command-construction tests for a Claude parent with Grok in both access modes, asserting the provider-specific permission mode and all retained sandbox/tool restrictions.
• Add or retain a fake-Grok runner test whose headless permission event would fail under plan/acceptEdits and succeeds under the selected non-interactive mode.
• Add receipt coverage that distinguishes parent sandbox/preflight failure from a Grok non-success terminal event.
• Run the runner test suite and strict TypeScript typecheck.
• Install the exact candidate in a Claude Code cloud profile and record setup read-only and dedicated-worktree write probes before merge.

[nirdrang]

Grok lanes refuse to start on Claude Code on the web: the cloud kernel has no Landlock, and the runner only passes Landlock-backed sandbox profiles

Summary

Open Pstack launches every Grok lane with --sandbox read-only (read-only lanes) or --sandbox workspace (isolated-write lanes). Grok Build 1.0.13 enforces those profiles with Landlock on Linux and refuses to start when the kernel cannot apply them. The Claude Code on the web VM kernel is built without Landlock, so every Grok lane exits in about two seconds with child-failed (runner exit code 70). The runner's preflight (grok models) passes, so the failure is only visible at lane start.

Claude and Codex lanes on the same session are unaffected.

Environment

• Claude Code on the web (cloud session), Firecracker VM, kernel 6.18.44-fc-v24
• Kernel config: CONFIG_SECURITY_LANDLOCK is not set; CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"; /sys/kernel/security/lsm does not exist
• landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION) returns -1, errno 38 ENOSYS
• Open Pstack 1.3.0 from the marketplace; main at c8481f7 builds the same Grok flags
• Grok Build 1.0.13, stable, 5e9a58528b76, static binary
• Claude parent, OAuth authentication, model grok-4.6 listed by grok models
• bubblewrap is not in the cloud image; I installed 0.9.0 by hand after the first failure (see Additional observations)

Reproduction

Every step below was re-run on 2026-09-09 and failed as described.

Run pstack-runner with these relevant options:

--parent claude
--provider grok
--model grok-4.6
--effort xhigh
--mode read-only

Use any prompt; a one-line prompt is enough.

The runner builds this Grok command (from the receipt's argv):

grok --prompt-file <prompt.md> --model grok-4.6 --reasoning-effort xhigh
     --permission-mode plan --sandbox read-only
     --tools read_file,grep,list_dir,run_terminal_cmd
     --disallowed-tools Agent,search_tool,use_tool
     --output-format streaming-messages-json --cwd <repo>
     --no-subagents --disable-web-search --verbatim

Grok exits 1 after about 2 s with one line on stderr:

error: could not apply the 'read-only' sandbox profile; see the warning above for the cause. Refusing to start with its protections missing.

The runner receipt:

preflight.status: passed  (authenticated; model grok-4.6 available)
exitCode: 1
status: child-failed
elapsedMs: 1884
error.message: child exited with status 1

Runner exit code 70.

The same happens for --mode isolated-write (--sandbox workspace, --permission-mode acceptEdits, runner exit 70 after 2.1 s), for --sandbox strict, and for the GROK_SANDBOX=read-only environment form. Grok alone reproduces it without the runner:

grok --sandbox read-only -p "reply ok" --output-format json; echo "exit $?"

Only --sandbox off and --sandbox devbox start on this kernel; both answer the prompt with exit 0.

To check a host before running a lane:

perl -e 'my $r=syscall(444,0,0,1); print "landlock_create_ruleset -> $r errno=$!\n"'

On the cloud kernel this prints errno=Function not implemented. On a kernel with Landlock it prints the ABI version.

If a grok wrapper is on PATH (see the workaround below), put the real binary first before reproducing: PATH=/root/.local/bin:$PATH.

Expected result

Either the runner detects a host that cannot apply the profile in preflight and reports it as such, in two seconds, with a receipt status that names the cause; or the runner lets the caller choose the Grok sandbox profile per host; or the docs say that Grok lanes need a Linux kernel with Landlock plus bubblewrap, so Claude Code on the web is a known unsupported host.

Verified local workaround

A wrapper first on PATH, named grok, that rewrites --sandbox read-only and --sandbox workspace to --sandbox devbox when the probe above says Landlock is absent, and is a no-op otherwise. Through it, read-only and isolated-write lanes complete with status: complete, reportedModel: grok-4.6-build, modelVerified: true. The wrapper also needs the two permission changes from issue #34 (see below), because devbox fences nothing and Grok then asks.

This is a workaround, not a proposed fix: devbox runs the lane unconfined.

Additional observations

1. bubblewrap comes first. On the stock cloud image the first refusal is a different one, in about 1.6 s, and grok models still passes:

    error: this sandbox could not enforce its deny list on Linux: bwrap exec failed: No such file or directory (os error 2). Install bubblewrap with `apt install -y bubblewrap`. Refusing to start with denied paths unprotected.
   

   After apt install -y bubblewrap the Landlock refusal above appears. So a Grok lane needs two host prerequisites that the runner's preflight does not check.

2. Grok's docs disagree with its behavior. ~/.grok/docs/user-guide/18-sandbox.md says "If the sandbox cannot be applied (e.g., unsupported kernel, missing entitlements), Grok logs a warning and continues without enforcement. The exception is an explicitly-requested custom profile". The built-in read-only, workspace and strict profiles refuse instead. The same file also says "Profiles that require it refuse to start if the kernel policy cannot be applied". The error text says "see the warning above", and no warning is printed in headless mode; --debug prints nothing more, and --debug-file <f> does not create the file.

3. Once Grok starts on devbox, headless permission prompts cancel the lane. This is issue Grok isolated-write lanes cancel headless edit permissions #34, and my trail matches it exactly: an isolated-write lane's first search_replace (creating a new file inside the lane's cwd) logged permission_requested, permission_resolved decision=cancelled wait_ms=0, turn_ended cancellation_category=permission_cancelled; runner status malformed-output, exit 65, after 12.9 minutes of work. The read-only variant is not in Grok isolated-write lanes cancel headless edit permissions #34: in --permission-mode plan, a shell command that writes a file (cat > report.md << 'EOF') logged the same three lines with tool_name=run_terminal_command and wait_ms=3, and the lane died after 7 minutes. A built-in read-only command (git log -1 --oneline) did not prompt.

4. What did not help: --debug, --debug-file, and the GROK_SANDBOX environment form, all with the same refusal.