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

5

Hey, thanks for the detailed report and for linking it to the related thread.

You got it right. This is a known issue we’re tracking, and I’ve added your case to it. The rejection is coming from a pre-check that runs before the actual review, so neither the approval card nor a retry with an approval request has time to show up. This pre-check currently trips on commands where the first token is an absolute path to the interpreter binary, like /tmp/.../venv/bin/python, and also on forms like python3 -, python3 -c, python3 -m, and on heredocs piped into the interpreter. Updating the desktop app won’t change anything since the check isn’t in the app, which you already confirmed by retesting on 0.44.0.

Until the fix ships, here’s a form that goes through normal review and will either run or show a card. Keep working_directory set to /tmp/meal-concierge-mc09-20260906 and run:

venv/bin/python extract_bundle_8333ae16.py <path to attachment> 85b30b00c8453426da982ca42fa5129526b4b73ff9866ddd006a3d85e9639e7b

What matters here:

  • The interpreter is given as a relative path, no leading /
  • The script is relative to working_directory
  • There are no flags between the interpreter and the script, like -I -B

Plain python3 extract_bundle_8333ae16.py ... should also work if the script isn’t too long, roughly up to a couple hundred lines. Until the fix is out, avoid absolute paths to executables, python3 -c and python3 - and python3 -m, and heredocs into the interpreter.

I can’t share a timeline yet, but I’ll reply in this thread when there’s an update. Let me know if the workaround doesn’t help.

7

Thanks, Dean. The suggested relative-Python form worked for a fresh extraction test: venv/bin/python extract.py ..., with an explicit working_directory and no interpreter flags. Grok reported exit 0 and successful extracted-file verification.

Before that, asking Grok to use ordinary unzip instead of Python extraction also got us past the initial blocker. We subsequently completed installation using the project’s existing ./install.sh entry point.

These are working routes, not evidence that the underlying bug is fixed. A separate installation attempt using relative Python and a script still received the binding rejection, so the extraction result does not establish a general fix. No Auto-review protections were disabled, and no cloud-computer reset was needed.

The tool results above come from Grok’s visible reports, not exported Shell telemetry. Your pre-check explanation accounts for the missing approval card. Thanks for tracking this.

8

Glad the relative-python setup and the unzip path workaround unblocked you. And you’re right, these are workable paths, not a sign the underlying issue is fully fixed. We’re still tracking it, I can’t share an ETA yet, and I’ll update the thread once we have news.

The part about a separate install attempt that still hit a binding rejection even with relative Python plus the script is a useful signal. To figure out whether that’s the same case or a different one, could you share:

  • The exact command that still failed (paths can be redacted)
  • Roughly how long the script you invoked is

If the script was clearly longer than a couple hundred lines, you might have hit the size limit I mentioned above, and then it’s a slightly different case. With the command and the size, I can be more precise and pass the right detail to the team.

9

Thanks, Dean. I checked the exact source version used: install.py was 560 lines (31,315 bytes), so your suggested size limit is plausible, though I can’t confirm that was the cause.

The command supplied to Grok for the failed attempt was (paths and task identifiers redacted; otherwise unchanged):

working_directory: /workspace/<task>/unpacked/<source>
command: ../../../../tmp/<probe>/venv-probe/bin/python install.py install --manager external --uv /usr/local/bin/uv --home /workspace/<task>/home --code-root /tmp/<task>/program --name <service-name> --provider mathem --household <household> --socket /tmp/<task>/service.sock

There were no interpreter flags or env prefix; --manager and the following options belong to install.py. Grok reported the same binding rejection before execution. As before, this is the submitted command plus Grok’s visible result, not independently exported Shell telemetry.

10

Thanks for clarifying the size and sharing the command. That helps separate two different cases.

Quick takeaway: the failed run is the same pre-check as in the main issue, not a size problem. Look at argv0: ../../../../tmp/<probe>/venv-probe/bin/python. Even though it’s written as a relative path, because it starts with ../ it resolves to the interpreter binary itself, and the pre-check tries to bind it as executable content. That’s the same bind reject we’re already tracking. It never even gets to the script or its size.

About 560 lines or 31,315 bytes: your guess is also on point, but from a different angle. If you ran bare python3 install.py ..., then install.py would be what the pre-check tries to read in full, and it would hit the limit around 8000 bytes or 200 lines. So this specific script gets hit from both sides. We’re tracking both limits.

The form that avoids both is a bare relative interpreter path without a leading /, ./, or ../. The pre-check doesn’t touch that kind of argv0, and it doesn’t depend on the script size. For your case, that means set working_directory to the folder that contains venv-probe, and pass the script path as an argument:

# working_directory: /tmp/<probe>
venv-probe/bin/python /workspace/<task>/unpacked/<source>/install.py install --manager external --uv /usr/local/bin/uv --home /workspace/<task>/home --code-root /tmp/<task>/program --name <service-name> --provider mathem --household <household> --socket /tmp/<task>/service.sock

Key point: the interpreter should be venv-probe/bin/python with no leading slash and no ../. The path to install.py is just a normal argument, so its size doesn’t matter.

I can’t share an ETA yet, but I’ll reply in the thread when there’s an update. Let me know if this form runs into anything else.