Grok Bot 0.44.0 on macOS: Shell executable-binding rejection persists; approval card never appears

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

An isolated synthetic Meal Concierge integration test cannot get past source extraction. Grok reports that Shell rejects the operation with:

Rejected: The executable content could not be bound to this review. Run the resolved script directly or provide an explicit working directory.

Requesting manual approval for the same command returns the same error. No user-visible approval card appeared, leaving no approval action for me to take.

Steps to Reproduce

  1. Grok reported successfully reading the uploaded ZIP and verifying its SHA256. It reported the new extraction/runtime destinations absent and no native MCP servers registered.
  2. The Python heredoc extraction command was rejected with the error above.
  3. Grok then reported writing a resolved script and invoking it with an absolute Python executable and explicit working_directory. The same rejection returned.
  4. At my request, Grok reported requesting an approval card for that exact same command with request_smart_mode_approval=true and smart_mode_block_reason set to the prior rejection. The same rejection returned; no card appeared.
  5. Grok stopped. It reported no extraction destination, new runtime, service startup or MCP registration created.

Reported command shape, with the attachment path redacted:

/tmp/meal-concierge-mc09-20260906/venv/bin/python -I -B /tmp/meal-concierge-mc09-20260906/extract_bundle_8333ae16.py [existing attachment path] 85b30b00c8453426da982ca42fa5129526b4b73ff9866ddd006a3d85e9639e7b
working_directory=/tmp/meal-concierge-mc09-20260906

Cloud execution with machineId omitted was requested. These paths refer to the environment reported by Grok; the actual invocation metadata was not independently available. The same task directory name was used for local preparation, so the path alone does not establish which computer executed the command.

Expected Behavior

For this authorized operation, either execute it or provide an actionable approval request. If another restriction prevents execution, explain it with a supported recovery route. Currently this blocks setup before Meal Concierge can start.

No Auto-review protections were disabled and no cloud-computer reset/update was performed during the documented sequence. Desktop app updating is separate: the error also persists in my 0.44.0 retest.

Operating System

MacOS

Version Information

Grok Bot desktop app on macOS. Initially observed on 0.43.0; I tested again on 0.44.0 on September 6, 2026, and the same error is still present. The detailed sequence in this report was recorded during the 0.43.0 test; I am not claiming a complete repeat of every step on 0.44.0.

Additional Information

The detailed command/tool results above come from Grok’s visible responses, not independently captured Shell telemetry. I directly observed the absence of an approval card. Initial extraction failure: approximately 20:30–20:31, September 6, 2026, Europe/Oslo (UTC+2). I can provide the intended runbook and available conversation/request identifiers privately to support; private identifiers and account email are omitted from this public post.

This appears related to the existing Shell Auto-review report. I have also sent the original report to support by email. Is there a supported fix or recovery procedure for this executable-binding failure?

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor