Bridge silently no-ops (exit 0, no output) when plugin root is a symlink

[benngermin]

Summary

Every /grok-build:* command is a silent no-op when the Claude Code plugin root is reached through a symlink. The bridge script exits 0 and prints nothing, so it looks like the command ran and produced no findings rather than like a failure.

Cause

scripts/grok-bridge.mjs guards its entrypoint by comparing the raw process.argv[1] against the module URL:

const isMain =
  process.argv[1] && path.resolve(process.argv[1]) === fileURLToPath(import.meta.url);

path.resolve() normalizes but does not resolve symlinks, while import.meta.url is the realpath Node resolved when loading the module. If any component of the invoking path is a symlink, the two strings differ, isMain is false, main() never runs, and the process exits 0 with no output.

This is not exotic: Claude Code supports multiple config homes (CLAUDE_CONFIG_DIR), and a common setup is to symlink plugins/ between them so one install serves every profile. The slash commands invoke the bridge via $CLAUDE_PLUGIN_ROOT, which then points at the symlinked path.

Reproduction

ln -s ~/.claude ~/.claude-alt

# silent, exit 0, no output
node ~/.claude-alt/plugins/cache/xai-grok-build/grok-build/0.2.1/scripts/grok-bridge.mjs check --json

# works
node ~/.claude/plugins/cache/xai-grok-build/grok-build/0.2.1/scripts/grok-bridge.mjs check --json

Observed on plugin 0.2.1, Node v24.18.0, grok 0.2.118, macOS.

Suggested fix

Resolve symlinks on both sides before comparing, with a fallback for paths that cannot be realpath'd:

const resolveEntrypoint = (candidate) => {
  try {
    return fs.realpathSync(candidate);
  } catch {
    return path.resolve(candidate);
  }
};

const isMain =
  process.argv[1] &&
  resolveEntrypoint(process.argv[1]) === resolveEntrypoint(fileURLToPath(import.meta.url));

fs is already imported in the module. Patching this locally makes every command work through the symlinked root.

Separately, it may be worth having an unknown/failed entrypoint state exit non-zero rather than 0, so a future variant of this fails loudly instead of looking like an empty result.

[kai-wedekind]

Independently reproduced on Windows, and it is slightly easier to hit there than in the macOS case you describe.

A directory junction triggers it identically, and junctions need no administrator rights or developer mode, unlike symlinks on Windows. Minimal repro, no plugin involved — just the guard both our trees use verbatim:

node <real>\probe.mjs   ->  MAIN RAN,   exit 0
node <junction>\probe.mjs  ->  (nothing), exit 0     <- main() never ran
    argv[1]  resolved: ...\symlinkprobe\link\probe.mjs
    meta.url resolved: ...\symlinkprobe\real\probe.mjs

Same two-paths-differ mechanism you identified, and mklink /J is enough to set it up.

Your second suggestion is the one I would push hardest for, beyond this specific bug:

it may be worth having an unknown/failed entrypoint state exit non-zero rather than 0, so a future variant of this fails loudly instead of looking like an empty result

That generalises well past isMain. An exit 0 with empty output is indistinguishable from a genuine "ran fine, found nothing", so it does not merely fail — it produces a false green that whatever called it will believe. I ran into the same shape from a different direction recently: a bash -c argument past a length limit gets silently truncated and returns exit 0 with no output, and the failure is invisible for exactly the same reason.

I carry this bug too, in a downstream fork, byte-identical since it is the same line — so thank you for finding it. I am fixing it there with both halves: realpath both sides, and an unrecognised entrypoint exits non-zero.

Are you planning to open the PR? Your fix looks right to me and you found it, so it should be yours. If you would rather not, I am happy to send one that credits you — just say which you prefer.

[TygartMedia]

Windows 11 repro + patch in #26 — npm test 67 pass / 0 fail on this machine (Grok 1.0.3).

[CarbeneAI]

Another macOS repro, with a third symlink topology beyond the two already in this thread.

Here the whole Claude config home is the symlink, not plugins/: ~/.claude points at ~/PAI/.claude, a git-tracked dotfiles repo. Any setup that keeps its Claude config in version control this way hits it on every /grok-build:* command.

$ node ~/.claude/plugins/cache/xai-grok-build/grok-build/0.2.1/scripts/grok-bridge.mjs check --json
$ echo $?
0

No output, exit 0. The same command through the realpath (~/PAI/.claude/...) prints the full check payload.

Environment: plugin 0.2.1, Node v26.6.0, grok 1.0.3 (1a29d5bc12d4), macOS 25.5.0.

I hit this on a fresh install and worked back to the same line before finding this issue. The patch applied locally is the same realpath-both-sides shape suggested above, including the path.resolve fallback in the catch, and it fixes every subcommand through the symlinked root.

One note for anyone else landing here: as of today main still carries the original line at 1097-1098 and plugin.json is still 0.2.1, so updating the plugin does not pick this up yet. PR #26 has the fix, bundled with unrelated Windows changes.

Agree on the exit-code point. Exit 0 with empty output is indistinguishable from "ran fine, nothing to report", which is why this read as a working check rather than a broken one.