Cursor-agent CLI never invokes hooks.json on Linux (2026.08.11) — same version works on macOS

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

cursor-agent CLI on Linux never invokes any hook defined in hooks.json — zero hook events fire. The identical CLI version on macOS, with the same hook entries, fires them correctly.

This is not the previously-reported partial event coverage (Cursor CLI doesn’t send all events defined in hooks, Cursor CLI hooks) — in those threads at least the shell-execution events fired, including for a Linux user on a January build. On 2026.08.11 on Linux, no event fires at all: not stop, not beforeShellExecution, not beforeSubmitPrompt, none. I verified this by making the first line of every hook command append to a logfile — the logfile is never created, so the hooks are never spawned (this is non-invocation, not hooks failing silently). Since a January-build Linux user did get shell events, this looks like a regression rather than never-shipped platform support; possibly related, the 2026.08.11 release notes include hook-execution changes (“Hooks defined by installed plugins … now execute and refresh”).

Steps to Reproduce

  1. On a Linux machine (mine is a Docker devcontainer, details below), create ~/.cursor/hooks.json:
{
  "version": 1,
  "hooks": {
    "stop": [{ "command": "echo \"$(date) stop\" >> /tmp/hook-probe.log" }],
    "beforeShellExecution": [{ "command": "echo \"$(date) shell\" >> /tmp/hook-probe.log; echo '{}'" }]
  }
}
  1. Run cursor-agent "run ls and tell me how many files there are" and let it complete a shell command and finish the turn.
  2. Check /tmp/hook-probe.log.
  3. Result on Linux: the file does not exist — neither hook was ever invoked. Same result with project-level .cursor/hooks.json, in both default and --force (Run Everything) modes, interactive TTY and headless.
  4. Control: the identical hooks.json on macOS with the identical CLI version — hooks fire (verified both with a manual probe and with cmux’s hook integration, which produced its notifications normally).

Expected Behavior

Hooks defined in hooks.json should be invoked on Linux the same as on macOS — or, if Linux is unsupported, that should be documented (the hooks page and the cli/headless docs currently make no platform distinction).

Operating System

Linux

Version Information

Ubuntu 26.04 LTS arm64 (Docker devcontainer; host: Amazon Linux 2023, kernel 6.18.39, aarch64). Control test on macOS 26.4 (Apple Silicon).
cursor-agent 2026.08.11-e8db854 (same version on both platforms)

Does this stop you from using Cursor

No - Cursor works, but with this issue

10

Hey @Jerico_Pingul, thanks for the detailed report, and apologies for the slow reply here.

We looked into this on our side, and the CLI is actually launching your hooks on that Linux machine. The hook processes are being spawned, but they fail after launch: some exit with code 127 (command not found), and others exit 0 without producing the output the CLI expects. The CLI currently does not surface these failures anywhere visible, which is why it looks identical to hooks never running. We want to make that more visible.

Since the hooks do run but your probe file never appears, the two most likely causes are:

  1. The hooks execute in a different environment from the one you are checking, for example /tmp inside the devcontainer vs /tmp on the EC2 host, so the file lands somewhere else.
  2. A shell profile on that machine interferes with the command (for example a profile that execs into another shell).

To pin it down:

  • Run cursor-agent --debug (or type /logs in an interactive session) and check the session log. It records every hook execution with its stdout, stderr, and exit code.
  • Change your probe hook command to hostname > /tmp/hook-probe.log 2>&1; pwd >> /tmp/hook-probe.log; env >> /tmp/hook-probe.log; echo '{}' and then check /tmp in both the devcontainer and on the host.

For your real hooks, exit 127 means the referenced command is not on PATH in the environment where the CLI runs them, so it is worth checking whether any helper scripts point at macOS-specific paths.

If you can share what the session log shows for one of these hook executions, we can dig in further!