GitNexus/gitnexus-cursor-integration
Minidoracat 0054496323
Some checks failed
CodeQL / Analyze (javascript-typescript) (push) Waiting to run
CodeQL / Analyze (python) (push) Waiting to run
Gitleaks / gitleaks (push) Waiting to run
Publish / Classify release event (push) Waiting to run
Publish / RC guard (marker + release-PR skip) (push) Blocked by required conditions
Publish / ci (push) Blocked by required conditions
Publish / Publish to npm (push) Blocked by required conditions
Publish / Build & Push RC Docker images (push) Blocked by required conditions
Scorecard / Scorecard analysis (push) Waiting to run
Trivy Image Scan / Trivy (gitnexus-cli) (push) Waiting to run
Trivy Image Scan / Trivy (gitnexus-web) (push) Waiting to run
Devcontainer Smoke / Config-transform unit tests (push) Has been cancelled
Devcontainer Smoke / Build devcontainer image (push) Has been cancelled
fix(hooks): wrap the augment CLI child in the orphan guard (#2163) (#2169)
* fix(hooks): wrap the augment CLI child in the orphan guard (#2163)

Follow-up invited by the maintainer on #2165: the augment child
(7s local / 12s npx) was the longest-lived unwrapped subprocess, exposed
to the same SIGKILL-orphan mechanism fixed for lsof/ps.

- Export resolveUnixGuardTimeout from the probe module (both copies,
  byte-identical); adapters share the same module instance, so the memo
  and lazy self-test still run at most once per hook process.
- Wrap every CLI-executing branch of runGitNexusCli in the three
  probe-equipped adapters with the guard: budget ceil(inner/1000)+1
  seconds with -k 1, strictly above each branch's inner spawnSync
  timeout, so the supervised path is unchanged and the wrapper only
  matters once the hook itself is SIGKILLed. Windows and no-guard hosts
  keep byte-identical argv. The plugin adapter's PATH-direct gitnexus
  branch (its most common production path) is wrapped too; the cheap
  which/where probe is not.
- Cursor integration: debug-gated 'augment skipped: hook slots
  saturated' on the slot-starved early return. Its augment child stays
  unwrapped for now — that integration does not install the probe
  sibling (the 'cursor probe' item on the #2163 follow-up list).
- Reaping tests get a guard-availability precheck with an explicit
  failure message (assertion, not skipIf, so a coreutils-less Linux
  host fails diagnosably instead of going silently green).
- Tests: orphaned-augment reaping (CJS + Plugin, red without the wrap,
  ~9.1s reap measured), disabled-sentinel degradation equivalence,
  source pinning for all three adapters (exact per-branch budget-formula
  counts) + probe export + cursor debug line.

Note: pre-commit typecheck skipped; remaining tsc errors are
pre-existing on main (none in files touched here).

* fix(hooks): group-SIGKILL the npx arm, prove guard exit propagation (#2169 review)

Addresses the tri-review findings on #2169:

- [P2] npx-arm containment: the CLI is the guard's grandchild there —
  at budget expiry coreutils timeout TERMs the group, npx (the obedient
  direct child) dies, timeout returns, and -k never fires, so a
  SIGTERM-immune grandchild escaped unbounded. The npx arm's wrapper now
  uses -s KILL: an unignorable group SIGKILL at budget that reaps the
  grandchild (kept -k 1 as a harmless belt; direct-exec arms keep
  TERM-first). CHANGELOG, adapter docblocks, and the test comment now
  state the per-arm semantics honestly. New behavioral test: a staged
  hook with a PATH-injected fake npx spawning a SIGTERM-immune
  grandchild is SIGKILLed; the grandchild must be reaped (red without
  -s KILL), with a route self-proof marker pinning the npx arm.
- [P3] guard self-test now proves exit-status propagation
  (sh -c 'exit 42' must yield status 42), so an always-exit-0 stub like
  /bin/true is rejected and resolution falls through to the built-in
  candidates instead of silently killing the augment feature. New test:
  stub guard rejected, augment still emits context.
- [P3] cleanup SIGKILLs in the reaping tests re-check the
  /proc/<pid>/cmdline identity immediately before firing (PID-reuse
  guard), applied consistently to the two pre-existing #2165 spots and
  both new tests.
- Review notes: source pins now constrain wrapper argv order and exact
  per-arm counts; adapters degrade to unwrapped on probe version skew
  (typeof check) instead of a swallowed TypeError; export JSDoc wording
  fixed for relative env paths; debug-gated diagnostic when no guard is
  available (e.g. macOS without coreutils), with the CHANGELOG entry
  qualified accordingly.

Note: pre-commit typecheck skipped; remaining tsc errors are
pre-existing on main (none in files touched here).

---------

Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>
2026-06-12 15:17:30 +01:00
..
hooks fix(hooks): wrap the augment CLI child in the orphan guard (#2163) (#2169) 2026-06-12 15:17:30 +01:00
skills fix(mcp): prevent sibling-clone repo ID collisions and correct generated MCP tool names (#2067) 2026-06-07 10:57:15 +01:00
README.md fix(cli): steer docs, skills, and hooks through a CLI-neutral project-local runner (#1939) (#1945) 2026-06-02 09:00:34 +01:00

GitNexus — Cursor integration

Static config that adds GitNexus knowledge-graph augmentation and skill files to Cursor.

Hooks require Cursor 2.4+. Earlier versions don't expose postToolUse and the hook will silently no-op.

What you get

Layer What it does How it's installed
MCP gitnexus MCP server with 16 tools (query, context, impact, detect_changes, rename, …) npx gitnexus setup writes ~/.cursor/mcp.json automatically.
Skills /gitnexus-exploring, /gitnexus-debugging, /gitnexus-impact-analysis, /gitnexus-refactoring, /gitnexus-pr-review markdown skills npx gitnexus setup copies them to ~/.cursor/skills/gitnexus/.
Hooks (this README) postToolUse hook that enriches Shell / Read / Grep tool calls with graph context — same augmentation Claude Code gets Manual — copy the files described below into your project's .cursor/.

Hook install

Cursor 2.4+ reads .cursor/hooks.json from the project root and runs hook commands with the project root as the working directory (docs).

From this repo's gitnexus-cursor-integration/hooks/, copy the files below into your project root:

<your-project>/
├── .cursor/
│   └── hooks.json              ← from gitnexus-cursor-integration/hooks/hooks.json
└── hooks/
    ├── gitnexus-hook.cjs       ← from gitnexus-cursor-integration/hooks/gitnexus-hook.cjs
    └── hook-lock.cjs           ← from gitnexus-cursor-integration/hooks/hook-lock.cjs

Equivalent shell commands (run from your project root, with $GITNEXUS_REPO pointing at a clone of this repo):

mkdir -p .cursor hooks
cp "$GITNEXUS_REPO/gitnexus-cursor-integration/hooks/hooks.json"        .cursor/hooks.json
cp "$GITNEXUS_REPO/gitnexus-cursor-integration/hooks/gitnexus-hook.cjs" hooks/gitnexus-hook.cjs
cp "$GITNEXUS_REPO/gitnexus-cursor-integration/hooks/hook-lock.cjs"     hooks/hook-lock.cjs

If you already have a .cursor/hooks.json, merge the hooks.postToolUse array rather than overwriting.

Verify

  1. Index the project: npx gitnexus analyze (on npm 11.x, npx can crash during install — use pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze instead; see #1939)
  2. Reload the Cursor window so it picks up the new hook config.
  3. Ask the agent something that triggers Read / Grep / Shell rg. You should see a [GitNexus] block appended to the tool result.
  4. Diagnose silent no-ops by setting GITNEXUS_DEBUG=1 in your shell environment — the hook will write Cursor's raw event payload to stderr so you can verify field names.

What's installed manually vs. automated

Step Automated by gitnexus setup?
~/.cursor/mcp.json
~/.cursor/skills/gitnexus/*
<project>/.cursor/hooks.json + <project>/hooks/gitnexus-hook.cjs + <project>/hooks/hook-lock.cjs — copy manually (see above)

Hook install is per-project (Cursor scopes hooks to a project root); skills and MCP config are global.

Hook contract

The hook receives a JSON event on stdin matching Cursor 2.4's postToolUse shape:

{
  "tool_name": "Grep" | "Read" | "Shell",
  "tool_input": { /* tool-specific */ },
  "tool_output": { /* optional */ },
  "cwd": "/absolute/path/to/project"
}

It writes augmentation context to stdout as:

{ "additional_context": "[GitNexus] …" }

Empty stdout means "no augmentation, continue normally" — the hook never blocks the tool.

Pattern extraction per tool

Tool Pattern source Notes
Grep tool_input.query (also pattern, regex, q, search, searchQuery) Last-resort fallback: longest string value in tool_input (≥ 3 chars).
Read basename of tool_input.target_file (also file_path, filePath, path, file), stripped to identifier characters auth/handler.tshandler.
Shell First positional argument after rg / grep in tool_input.command Best-effort tokenizer; quoted multi-word patterns (rg "User Service") extract the first word only.

Troubleshooting

  • Nothing happens — Confirm Cursor is on 2.4+ and the project root has .cursor/hooks.json plus both hook files at hooks/gitnexus-hook.cjs and hooks/hook-lock.cjs. Then npx gitnexus list to confirm the project is indexed.
  • gitnexus not found — The hook prefers a locally-resolvable gitnexus/dist/cli/index.js and falls back to npx -y gitnexus. Install globally with npm i -g gitnexus to skip the npx cold-start latency.
  • Wrong pattern extracted — Set GITNEXUS_DEBUG=1 and run a tool call. The raw stdin payload is logged to stderr; use it to confirm Cursor's actual tool_input field names against the table above. If they differ, file an issue with the captured payload.