DEV Community: jackymenCZ (jackymenCZ)

Windows GUI check — published sentinel-ir-mcp 0.5.9. The No-Login Paradox 2

jackymenCZ (jackymenCZ) — Sun, 15 Nov 2026 18:25:05 +0000

Verdict

Source (GitLab, Apache-2.0): https://gitlab.com/jakubrojicek11/sentinel-ir
npm: https://www.npmjs.com/package/sentinel-ir
Playground (runs in your browser): https://sentinel-ir-playground-dc30c8.gitlab.io/

Desktop startup is verified; desktop-originated tool calls remain untested. Normally installed VS Code and its Cline extension both started the published server without signing in. Actual analysis calls passed through the MCP Inspector browser fallback, not a desktop client.

VS Code also reproduced the reported Error/empty-output symptom, but on its session-bound server entry. The separate locally configured / Global in Code entry started successfully with the same configuration. Evidence points to VS Code's session/policy surface, not a broken Sentinel executable. The exact underlying VS Code policy requirement is not established.

Environment and configuration

Windows Server 2022; VS Code 1.146.0, official user installer, not portable.
Onboarding bypassed with Continue without Signing In. No Microsoft/GitHub/Cline login.
Primary runtime Node 22.23.5, secondary Node 24.22.2; spawned server ExecutablePath checked using Win32_Process, not inferred from shell PATH.
Project: C:\t\Projekt Žluťoučký kůň\app; files src\index.js, src\util.js, src\main.rs, tool.py.
Setup invoked as npx -y sentinel-ir-mcp@0.5 setup --client vscode. It printed a command; it did not write configuration.
Registered using the printed code --add-mcp form; resulting user configuration: %APPDATA%\Code\User\mcp.json.
Actual running package: %LOCALAPPDATA%\npm-cache\_npx\3ec5bc0582433d0b\node_modules\sentinel-ir-mcp\package.json → 0.5.9. Both Node versions used this published npm cache installation.

VS Code's generated entry:

{"type":"stdio","command":"npx","args":["-y","sentinel-ir-mcp@stable-0.5","C:\\t\\Projekt Žluťoučký kůň\\app"]}

For Cline and Inspector, copied the Windows JSON-client form confirmed by setup --client claude-desktop --project "<project>" --config <temporary-file> --dry-run:

{"command":"cmd","args":["/c","npx","-y","sentinel-ir-mcp@stable-0.5","C:\\t\\Projekt Žluťoučký kůň\\app"]}

Verified results

Client / surface	Started?	Tools / calls
VS Code 1.146.0, local user entry, Node 22	Yes	`Running`; `Discovered 3 tools`; real Sentinel Node 22 process. Initial restricted workspace worked; trusting it and restarting also worked.
Cline 4.1.26, Node 22, generated `cmd /c npx`	Yes	Green connected indicator; schemas for `analyze_code`, `analyze_file`, `analyze_directory`. Calls untested: no configured working model. Selected local Ollama provider to finish onboarding without an account; no model service was installed.
MCP Inspector 2.15.0 browser fallback, Node 22, same `cmd /c npx`	Yes	All three tools listed. Both required real calls passed; results below.
VS Code 1.146.0, session-bound entry after relaunch, Node 24 environment	No	`Error`, empty MCP output; renderer: `Could not list installed MCP servers. (refused: policy-context-unavailable)`. No additional Sentinel process from this attempt. Cline's separately running Node 24 server was not mistaken for this entry.
VS Code 1.146.0, local / Global in Code entry, Node 24	Yes	Same generated `npx` configuration; `Running` + `Discovered 3 tools`; separate actual Node 24 server process.
VS Code local entry, Node 24, `npx.cmd` variant	Yes	Changed only command from `npx` to `npx.cmd`; `Running` + `Discovered 3 tools`. Original generated configuration restored afterward.

Inspector calls: entered absolute Czech/spaced paths through visible tool forms and clicked Execute Tool.

analyze_file on ...\src\index.js: OK, 75 ms in result pane; analysisStatus: complete, language: javascript, risk: medium, filesystem and network recognized (fs.readFileSync, https.get).
analyze_directory on project root: OK, 39 ms; 4 analyzed, 4 complete, 0 incomplete, no timeout/truncation; Rust/Python critical (process spawning), index.js medium, util.js low.

Protocol monitoring panel separately displayed approximately 73 ms / 34 ms for those calls. No CLI/SDK call is being presented as GUI coverage.

Visual evidence

VS Code Node 22 — running	Cline — connected and tools

Inspector fallback — file result	Inspector fallback — directory result

🔴 VS Code session entry — Error	🟢 Same runtime, local entry — Running / 3 tools

Failure evidence and limitations

Exact working route after relaunch: MCP: List Servers → Show locally configured servers… → sentinel-ir (Global in Code) → Start Server.
Session-bound failure output file was empty. Full failure-time logs are preserved in vscode-node24-failure-logs; focused renderer.log, exthost.log and full subsequent local MCP log are also supplied in windows-mcp-logs.zip.
Generated npx and alternate npx.cmd both work locally; cmd /c npx works in Cline and Inspector. The session-bound entry was not fully retested with every command variant. Switching to the local surface resolved startup without any command change.
Desktop analysis calls, account-policy root cause, and Node 24 analysis calls: untested. Inspector demonstrates server tools, not desktop model orchestration. No claim that Copilot model usage works without sign-in.
No source-code, repository, or MR changes. No unit-test results substituted for runtime coverage.
Recording required recovery after an unfinalized MP4 stop. The supplied condensed video is reconstructed from the original desktop H.264 frames, with idle sections removed, two labeled portions at 2× speed, and explanatory overlays; it is not a second test run. Screenshots/logs are the primary evidence.

Facts vs interpretation: successful local launches and Inspector tool responses are observed facts. Session/policy routing is the best-supported explanation for the failed entry; these tests do not establish which VS Code setting or sign-in would repair that session-bound route. No Sentinel launch failure was observed on the functioning local/client routes.

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Sentinel Ecosystem: AutoDoc-Sentinel, Sentinel-IR, Sentinel-IR-MCP and related tools.
Agentix Lite: Independent security and system-observation project.
Find the projects: GitLab repositories | NPM packages

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

sentinel-ir 0.5.9 / sentinel-ir-mcp 0.5.9: ordinary-user test, round 3 (macOS)

jackymenCZ (jackymenCZ) — Sun, 15 Nov 2026 17:53:37 +0000

Machine: macOS 26.6.2 (Darwin 25.6.0), Apple Silicon arm64
Node: 20.20.2 (npm 10.8.2), 22.23.5 (npm 10.9.9), 24.22.3 (npm 11.19.1). The desktop-client runs used Homebrew Node 24.21.0 (npm 10.8.3).

Packages: everything came from the npm registry (sentinel-ir@0.5.9, sentinel-ir-mcp@0.5.9, stable-0.5 = latest = 0.5.9). I read the version of the copy that actually ran from its package.json in ~/.npm/_npx/<key>/node_modules/... each time. No repo checkouts, no code changes, no MRs.
MCP client: a real @modelcontextprotocol/sdk Client + StdioClientTransport that starts npx -y sentinel-ir-mcp@... <folder>. I also used VS Code 1.146.0, Cursor 3.30.14 and Claude Desktop 5.11492.5.

Summary

There are no blockers. Every 0.5.9 fix in scope works at runtime on macOS. The remaining problems are in doctor's output, a gap between the library README and its behaviour, and some smaller papercuts.

#	Severity	Issue
1	bug	`doctor --client vscode` / `claude-code` prints `[ok] Excluded: nothing` and `[ok] Audit log: off` even when the real client entry has `--exclude=secrets --audit-log`
2	bug	`doctor`'s stale-npx-cache check misses a pinned `@0.5.8` copy, and it labels every stale copy `sentinel-ir-mcp@^0.5.8`, whatever the user actually wrote (`@0.5`, `@latest`)
3	bug (docs)	Library: an explicit unsupported `language` (`"ruby"`) returns `language: "ruby"` with the message under `facts.error`. The README promises `language: "unknown"` and `facts.reason`
4	docs	Library README "Field reference" shows `world.risk` / `mission.objective`, but `analyze()` returns flat `risk` / `objective`, so `ir.world.risk` throws a TypeError
5	docs	Library README "Why send IR" size table and the "about 400 characters" claim are out of date for 0.5.9
6	papercut	`doctor` prints `[ok] analyze_directory works ... (0 file(s) checked)` when nothing was checked
7	papercut	Fix-it hints from `doctor` and `setup` leave out `--client` (and `--global`), so copying them fails outside a TTY or changes the wrong config
8	papercut	MCP `analyze_code.language` is case-sensitive (`"JS"` gives a -32602 error); the library accepts `"JS"`
9	papercut	`mailto:...` / `data:...` are treated as relative file names (`Not found`), not refused as URLs
10	papercut	URL refusal text is formatted differently from every other refusal
11	papercut	The folder summary line in `log` leaves out the skipped-symlink and incomplete counts
12	papercut	Different per-file shapes in `analyze_directory` (`riskSignals` without `forbidden` for parsed files, `forbidden` with empty `riskSignals` for broken ones)
13	papercut	Rust: idiomatic `use std::process; process::exit(0)` in a broken file is `critical` with `forbidden: ["child_process"]`. A parsed `process::exit` is `low` but still has `forbidden: ["process.exit"]` (a JS-style name)
14	papercut	`examples/basic.js` on a missing file prints a raw Node `ENOENT` stack trace
15	papercut	Cosmetic: ragged line wrap in `guide` step 2, uneven sub-line indentation in `doctor`
16	docs	MCP README: the audit-log reason list leaves out `not-a-folder`; "What the server can and cannot do" leaves out the URL / UNC refusals; the minimum `sentinel-ir` version appears only in the changelog
17	docs	MCP README says npx range copies stay stale "incl. npm 11.21.2"; on npm 11.19.1 the `@0.5` copy was refreshed
18	docs	Library README alias column lists `py` / `rs` only; `js` / `ts` (and upper case) also work

Results of the 8 regression checks

#	Check	Result
1	UNC / remote `file://` refused before any FS/network access	PASS (macOS semantics). `//server/share/x.js` → `Access denied: ... is outside the allowed folders`. `file://server/share/x.js`, `file://192.168.1.50/share/x.js` and `smb://192.168.1.50/s/x.js` → `path must be a file path, not a URL`. `file:////192.168.1.50/s/x.js` → outside. `\\server\share\x.js` → `Not found`, which is correct on POSIX because `\` is an ordinary file-name character. `tcpdump -i any` on ports 445/139/137/53/5353 during the calls: zero SMB packets and no DNS lookup for `server` or the IP (only unrelated Apple DNS).
2	`file:src/x.js`, `http(s)://`, `ftp://` refused as URLs; local `file:///` works	PASS. `file:src/x.js`, `file:src/app.js` (the file exists), `http://`, `https://`, `HTTP://` and `ftp://` all give `path must be a file path, not a URL`. `file:///<root>/src/app.js` (raw and percent-encoded, with spaces and `ž`) and `file://localhost/...` analyse fine. On another volume the local `file://` URL also works. Side note: `mailto:` / `data:` are not covered (#9).
3	Broken Python/Rust is `critical` only when `forbidden` names the capability	PASS. Broken files with `subprocess`, `os.system`, `runpy`, `spec_from_file_location(...).loader.exec_module`, `from ctypes import *` and `std::process::Command` (short and full path) → `critical`, with the capability in `forbidden`. Harmless ones (`importlib.reload`, `from ctypes import c_int`, `std::process::exit`, `std::process::id`, `std::io::stdin`, plain code) → `low`, `forbidden: []`. Same results on Node 20/22/24 and through MCP. Bare `import pickle` / `import ctypes` / `use std::process` → `critical` as documented (see #13).
4	`analyze_directory` summaries list `forbidden` for dangerous broken files	PASS. In a folder of 11 dangerous and 7 harmless broken files, the 11 are `critical` with `forbidden` and the 7 are `low` without `forbidden`.
5	`analyze_code.language` accepts `js`, `ts`, `py`, `rs`	PASS. All four work, and the enum is in the tool schema. Upper-case `"JS"` is rejected (#8).
6	`log` wording	PASS. `x.rb` → "incomplete: unsupported language". Remote URL → "not a local file path". Outside → "outside the allowed folders". Hard link → "file has several hard links". In a folder, "3 not read (several hard links)" and "1 not read (too large or unreadable)" are separate. "not a folder" / "not a file" are correct. Symlink and incomplete counts are missing from the folder line (#11).
7	`doctor`: unmatched exclusion warning; stale-cache wording for range vs tag	PARTIAL. The unmatched-exclusion warning works (`[warn] ... matches nothing`). The stale-cache warning appears, but it always names the npx-internal range `^0.5.8` instead of the user's spec (`@0.5`, `@latest`) and misses a pinned `@0.5.8` copy (#2).
8	README documents `language` + aliases, every refusal reason, minimum `sentinel-ir`	PARTIAL. The MCP README Tools table documents `language` and its aliases. The refusal reasons are spread across the changelog and the security section, and `not-a-folder` is missing from the audit-log list. "Needs sentinel-ir 0.5.9" appears only in the changelog (#16).

0.5.8 fixes rechecked, all still OK: the same Access denied for existing and missing outside paths (including .., src/../.. and a dangling symlink); .rb / .go → incomplete / unknown; doctor --client works for each of cursor, windsurf, claude-desktop, vscode and claude-code; log | head -1 exits cleanly with no EPIPE; strict TypeScript declarations; Rust/TSX parse positions; .jsx accepted.

Issues

1. bug: `doctor --client vscode` reports exclusions and audit log that contradict the real config

OS / Node: macOS 26.6.2 arm64, Node 24.21.0 (Homebrew). The same code path runs on 20/22/24.
Repro:
1. cd "/Users/devin/Projekty/Můj projekt ž"
2. npx -y sentinel-ir-mcp@stable-0.5 setup --client vscode --exclude secrets --audit-log, then run the printed code --add-mcp '{...}' command. VS Code writes ~/Library/Application Support/Code/User/mcp.json containing "--exclude=secrets", "--audit-log".
3. npx -y sentinel-ir-mcp@stable-0.5 doctor --client vscode
Expected: Because doctor cannot read VS Code's list, it should not say anything about exclusions or the audit log, or it should say "unknown, check the VS Code entry". It should not report [ok] Excluded: nothing.
Actual: It says, as [ok], that nothing is excluded and the audit log is off, which is the opposite of the real setup. A user who checked can come away thinking their secrets exclusion is gone, or that it is not needed.
Full output:

[ok]   Node.js v24.21.0
[ok]   sentinel-ir-mcp 0.5.9, sentinel-ir 0.5.9
[ok]   sentinel-ir-mcp 0.5.9 is the newest stable-0.5 on npm
[ok]   npx cache (/Users/devin/.npm/_npx): no copy with sentinel-ir older than 0.5.9
[skip] VS Code keeps its own server list; check it there (VS Code: "MCP: List Servers", Claude Code: "claude mcp list").
[ok]   Excluded: nothing (the agent may analyze every source file in the folder)
[ok]   Audit log: off (turn it on: npx -y sentinel-ir-mcp@stable-0.5 setup --audit-log)
[ok]   MCP handshake with sentinel-ir-mcp 0.5.9
[ok]   Tools: analyze_code, analyze_directory, analyze_file
[ok]   analyze_directory works on /Users/devin/Projekty/Můj projekt ž (1 file(s) checked)

All checks passed.

The actual mcp.json:

{ "servers": { "sentinel-ir": { "type": "stdio", "command": "npx",
  "args": ["-y","sentinel-ir-mcp@stable-0.5","--exclude=secrets","--audit-log","/Users/devin/Projekty/Můj projekt ž"] } }, "inputs": [] }

The audit-log hint has the same problem: setup --audit-log without --client vscode would not change this entry (see #7). I did not run claude-code separately; the [skip] line shows it takes the same branch.

2. bug: the stale-npx-cache warning misses a pinned copy and names a range the user never wrote

OS / Node: macOS 26.6.2 arm64, Node 20.20.2 / npm 10.8.2. Isolated HOME=/Users/devin/r3/hup20.
Repro (pinned copy missed):
1. npx -y sentinel-ir-mcp@0.5.8 --version → 0.5.8. The cache key e90bfea4b29781f8 = sha512("sentinel-ir-mcp@0.5.8"), and its package.json has 0.5.8 / sentinel-ir 0.5.8.
2. npx --before=2026-11-15T16:00:00Z -y sentinel-ir-mcp@latest --version → 0.5.8 (key 44517f9a0f1686df = @latest).
3. npx -y sentinel-ir-mcp@stable-0.5 doctor --client cursor
Actual: Doctor reports only the @latest copy:

[warn] The npx cache still holds sentinel-ir-mcp@^0.5.8 (sentinel-ir-mcp 0.5.8, sentinel-ir 0.5.8) in /Users/devin/r3/hup20/.npm/_npx/44517f9a0f1686df; a client entry with that version or range keeps starting it, and sentinel-ir older than 0.5.9 misses security fixes
       -> Close the client, delete that folder (npm 11: npm cache npx rm 44517f9a0f1686df), then run: npx -y sentinel-ir-mcp@stable-0.5 setup
...
All checks passed, 1 warning above.

Then move 44517f9a0f1686df away and run doctor again. It prints All checks passed. with no warning, even though e90bfea4b29781f8 (a pinned @0.5.8, the one copy that really does keep starting 0.5.8 forever) is still in the cache with sentinel-ir 0.5.8.
The @latest copy that was flagged gets refreshed by npm 10 itself: npx -y sentinel-ir-mcp@latest --version → 0.5.9, and its package.json → 0.5.9.

Repro (wording): seed @0.5 the same way (npx --before=... -y sentinel-ir-mcp@0.5 --version), then run doctor. The warning names sentinel-ir-mcp@^0.5.8 for key 46f9bf218df4163a (= sentinel-ir-mcp@0.5). That is the range npx writes into its private package.json; the user's config says sentinel-ir-mcp@0.5. For the @latest key it also says ^0.5.8, so the message reads the same for a range and a tag.
Expected: Every cached copy with sentinel-ir < 0.5.9 is listed, labelled with the spec a client entry would contain (sentinel-ir-mcp@0.5, @latest, @0.5.8). The text says which of them npx refreshes by itself (tags) and which stay stale (pinned versions; ranges on npm 10).
Note: the hint shows npm 11: npm cache npx rm ... on npm 10, which is labelled and fine.

3. bug (docs vs behaviour): an explicit unsupported `language` is not reported as `unknown`

OS / Node: macOS 26.6.2 arm64, Node 20/22/24 (same result).
Repro: npm install sentinel-ir, then

const { analyze, compress } = require("sentinel-ir");
const ir = analyze("x = 1", { language: "ruby" });
console.log(ir.language, ir.analysisStatus, ir.facts, compress(ir).facts);

Expected (README §Languages): "An explicit unsupported language (e.g. "ruby") ... is reported as analysisStatus: "incomplete" with language: "unknown" and facts.reason: "unsupported file type: .rb (…)"".
Actual:

ruby incomplete { error: 'unsupported language: ruby (supported: javascript, typescript, tsx, python, rust)' } { ast: false, reason: 'unsupported language: ruby (supported: javascript, typescript, tsx, python, rust)' }

language is "ruby", not "unknown". The raw IR puts the message in facts.error, not facts.reason (only compress() uses reason). A target with an unknown extension (x.rb) does give unknown + facts.reason, so the two paths are inconsistent. Code that checks ir.language === "unknown" misses this case. Also, analyze("eval(1)", {language:"ruby"}) comes back incomplete + critical from the text heuristics. That is fine, but the README does not say it.

4. docs: the library README field reference does not match the shape `analyze()` returns

OS / Node: macOS, Node 20/22/24.
Repro: following the README, const ir = analyze(src, { target: "app.js" }); console.log(ir.world.risk);
Expected: prints the risk, since the README "Field reference" documents world.risk, mission.objective and so on.
Actual:

TypeError: Cannot read properties of undefined (reading 'risk')

The raw IR is flat (ir.risk, ir.target, ir.objective, ir.forbidden, ir.analysisStatus, ir.facts). Only compress(ir) has world / mission. The shipped .d.ts is correct, so TypeScript users find out at compile time and JS users at runtime. The README should say which shape each section describes.

5. docs: the library "Why send IR" table and the "about 400 characters" claim are out of date

OS / Node: macOS, Node 22. node node_modules/sentinel-ir/examples/basic.js <file> on the package's own files.
README: ast-facts.js 21,823 → 449; sentinel-ir.js 9,123 → 515; tree-parser.js 4,393 → 465; basic.js 600 → 461; "about 400 characters plus the facts".
Actual 0.5.9: ast-facts.js 96,821 → 511; sentinel-ir.js 20,413 → 621; tree-parser.js 13,175 → 803; basic.js 600 → 510/532. The ratio claim still holds, but the numbers no longer match.

6. papercut: `doctor` says `[ok] analyze_directory works` after checking 0 files

OS / Node: macOS, Node 22.23.5.
Repro: mkdir "p q" && cd "p q" && echo 'eval(1)' > a.js && ln -f a.js ../a_link.js (so the only file has 2 links), then npx -y sentinel-ir-mcp@stable-0.5 setup --client cursor --no-exclude --no-audit-log --yes and npx -y sentinel-ir-mcp@stable-0.5 doctor --client cursor.
Expected: [warn] "no file could be analysed (1 skipped: several hard links)", or at least no "works" claim.
Actual:

[ok]   analyze_directory works on /Users/devin/r3/hl/p q (0 file(s) checked)

All checks passed.

I saw the same on the second volume when the first candidate file was a hard link.

7. papercut: copy-paste hints leave out `--client` / `--global`

OS / Node: macOS, Node 20/22/24.
Repro A: the stale-cache hint in #2 ends with then run: npx -y sentinel-ir-mcp@stable-0.5 setup. Run from a script, CI or a non-TTY terminal:

sentinel-ir-mcp setup: Choose a client with --client (cursor, windsurf, claude-desktop, vscode, claude-code).

Repro B: npx -y sentinel-ir-mcp@stable-0.5 setup --client cursor --global --dry-run prints Audit log: off (turn it on with: npx -y sentinel-ir-mcp@stable-0.5 setup --audit-log). The hint drops --client cursor --global, so in a TTY it asks again, and it may target the project config instead of the global one. Doctor for vscode prints the same hint (#1).
Expected: the hints repeat the --client (and --global) that was used. Related: the README says "without --client it asks", but it only asks on a TTY. With stdin piped it exits with the message above. That is reasonable behaviour, but the README should mention it.

8. papercut: MCP `analyze_code.language` is case-sensitive while the library is not

OS / Node: macOS, Node 20/22/24, via the MCP SDK client.
Repro: callTool("analyze_code", { code: "eval(1)", target: "a.js", language: "JS" })
Actual:

MCP error -32602: Input validation error: Invalid arguments for tool analyze_code: Invalid option: expected one of "javascript"|"typescript"|"tsx"|"python"|"rust"|"js"|"ts"|"py"|"rs" at language

The library analyze("eval(1)", { language: "JS" }) → language: "javascript", complete, critical. The error message itself is clear; this is a consistency issue only.

9. papercut: `mailto:` / `data:` paths are treated as relative file names

Repro (MCP, Node 24): analyze_file { path: "mailto:a@b.js" } and analyze_file { path: "data:text/javascript,eval(1)" }.
Actual: Not found: mailto:a@b.js, Not found: data:text/javascript,eval(1).
Expected: the same path must be a file path, not a URL as file:src/x.js / http://, which the 0.5.9 changelog describes as covering "other URLs". There is no security impact (they resolve inside the root and do not exist), but the wording is inconsistent.

10. papercut: the URL refusal is formatted differently from the other refusals

Other errors start with a capitalised label and name the path: Access denied: X is outside the allowed folders, Not found: X, File too large: big.js is 1800000 bytes, limit is 1048576, Unsupported file type: ..., Not a file: .... The URL refusal is a lowercase sentence that does not name the path: path must be a file path, not a URL. Suggested wording: Not a file path: <value> is a URL.

11. papercut: the folder summary in `log` leaves out the symlink and incomplete counts

Repro: analyze_directory on a folder with 3 symlinks, 3 hard links, 1 oversized file and broken files, then npx -y sentinel-ir-mcp@stable-0.5 log.
Actual: the folder line lists the analysed files, "3 not read (several hard links)" and "1 not read (too large or unreadable)". The 3 skipped symlinks and the number of incomplete files, both in the tool result, do not appear in the log.
Expected: the same counts the agent saw, since the log is the user's record of what the agent got.

12. papercut: inconsistent per-file entries in `analyze_directory`

Parsed files have riskSignals (e.g. ["dynamic_code:eval@4"]) and no forbidden key. Broken files have forbidden and riskSignals: [], even when they are critical. A consumer has to read both fields to find out why a file is risky. The guide tells agents to look at riskSignals, so for a broken critical file they see an empty list.

13. papercut: Rust `process::exit` naming in broken and parsed files

Repro (library, Node 22):
- A broken file containing use std::process; … process::exit(0) (Rust Book ch. 12 style) plus a syntax error → critical, forbidden: ["child_process"]. The same file without the syntax error → low.
- A parsed file with std::process::exit(1) → risk: "low" but forbidden: ["process.exit"].
The bare use std::process rule is documented, but a "child_process" label on Rust code that only exits looks wrong to a newcomer. A non-empty forbidden with a JS name at low risk is confusing.

14. papercut: `examples/basic.js` prints a stack trace for a missing file

Repro (Node 22): node node_modules/sentinel-ir/examples/basic.js nope.js
Actual:

node:fs:440
    return binding.readFileUtf8(path, stringToFlags(options.flag));
                   ^

Error: ENOENT: no such file or directory, open 'nope.js'
    at Object.readFileSync (node:fs:440:20)
    at Object.<anonymous> (/Users/devin/r3/lib22/node_modules/sentinel-ir/examples/basic.js:7:17)
    at Module._compile (node:internal/modules/cjs/loader:1781:14)
    ...

Expected: a one-line basic.js: cannot read nope.js plus usage. Also, npx sentinel-ir file.js gives npm error could not determine executable to run. The README does not promise a CLI, but a newcomer will try it.

15. papercut (cosmetic): text layout

guide step 2 has a ragged wrap:

2. Look at "incomplete", "skipped.unreadable" and "skipped.hardlinks" before
   anything else. Those
   files were not fully analyzed: ...

In doctor, the sub-lines under [ok] and [warn] items are indented differently ([ok] in ... vs [warn] matches nothing).

16. docs: gaps in the MCP README

The audit-log section lists why a request was refused (excluded, outside, ...) but leaves out not-a-folder, which log does print.
"What the server can and cannot do" (the section a cautious user reads) does not mention that URLs, file: without //, remote file://host/ and UNC paths are refused. That is only in the 0.5.9 changelog.
The minimum sentinel-ir version (0.5.9) is stated only in the changelog, not in "Dependencies" or "Setup".

17. docs: npx range refresh depends on the npm version

Repro: seed npx --before=2026-11-15T16:00:00Z -y sentinel-ir-mcp@0.5 --version (→ 0.5.8, cache package.json 0.5.8 / 0.5.8), then npx -y sentinel-ir-mcp@0.5 --version.
npm 10.8.2 (Node 20): stays 0.5.8, as the README says.
npm 11.19.1 (Node 24): 0.5.9, and the cache 46f9bf218df4163a → 0.5.9 / 0.5.9.
The README says range copies stay stale and that this was "measured incl. npm 11.21.2". The advice (use @stable-0.5) is still right, but the sentence should say the behaviour depends on the npm version.

18. docs: the library alias list is incomplete

The library README table shows python (alias py) and rust (alias rs) only. js, ts and upper-case names (JS) also work, and the MCP README lists js / ts.

What I verified works

sentinel-ir (Node 20, 22, 24)

npm install sentinel-ir in a fresh project. npm 11 prints the install-scripts ... allowScripts notice for tree-sitter*, which the README mentions; analysis works regardless (native prebuild on darwin-arm64, WASM for the others).
The README Usage example output matches the README exactly. examples/basic.js works on JS, JSX, TS, .d.ts, TSX, Python and Rust.
Files that do not parse fall back to heuristics with facts.ast: false and correct positions: broken.js 1:11 unclosed (, broken.tsx 1:29 unclosed {, broken.rs 1:11 unclosed {, Python 2:7 missing ).
.rb / .go targets → incomplete, unknown, unsupported file type reason. Sync Python without init → incomplete with a clear reason.
Output is identical on all three Node versions.
Strict TypeScript (module = nodenext, bundler, preserve): the shipped declarations type-check, aliases are typed, ESM import works, and wrong argument types are caught.

sentinel-ir-mcp (Node 20, 22, 24)

npx -y sentinel-ir-mcp@0.5 --version / -v, --help, guide, log; log | head -1 exits without EPIPE.
setup: interactive on a TTY (cursor, with exclusions + audit log), --yes is idempotent, --dry-run, --global, --project <dir>. Windsurf and Claude Desktop JSON is valid. VS Code / Claude Code print a working command. Re-running preserves keys that Claude Desktop added (preferences) and makes a backup.
doctor per client, a real MCP handshake, the unmatched-exclusion warning, the warning for a pinned or old entry ("run setup"), and the 0.5.8 self-check ("This is sentinel-ir-mcp 0.5.8, npm has 0.5.9 ... runs from the npx cache (...)").
MCP stdio with the SDK client: analyze_code, analyze_file and analyze_directory all work, including paths with spaces and ž ü and a ..cache/ folder name. Refusals: outside existing/missing/../src/../../dangling symlink → the same Access denied; symlink out → outside; hard link → has 2 hard links; files with more than one are refused; big.js → File too large: big.js is 1800000 bytes, limit is 1048576; .md / Makefile / .rb → Unsupported file type ... (only ...); excluded (existing and missing) → the same refusal; Not a file / Not a folder; file:///etc/passwd → outside; empty path → schema error.
The audit log records every case above with distinct wording (check 6).
First connect on a fresh cache took about 1.8 s; npm's "npm 12" notice goes to stderr and does not break stdio.

Upgrade from 0.5.8 (README flow, npm 10.8.2)

Seeded @0.5 and @stable-0.5 with --before → cache package.json 0.5.8 / 0.5.8. Then @stable-0.5 → 0.5.9 (cache 3ec5bc0582433d0b 0.5.9 / 0.5.9), while @0.5 stays 0.5.8, as documented. Doctor warns (with the wording problem in #2). Following the README (close the client, delete the folder, setup --client cursor --yes) rewrites the entry to @stable-0.5. The command in the config then runs 0.5.9, confirmed from the cache package.json, and doctor is all [ok].

Another volume

APFS disk image mounted at /Volumes/Druhý disk, project Moje projekty/app ž (Node 22). Relative and absolute paths and file:// URLs work. A symlink back to the boot volume is refused as outside, and hard links are refused. analyze_directory works. setup --client claude-desktop --project "<vol path>" --audit-log --yes works, doctor is OK, and the exact command from the generated config starts the server.

Desktop clients (no login)

VS Code 1.146.0: the printed code --add-mcp command → "Added MCP servers: sentinel-ir"; mcp.json is correct, including the non-ASCII path. "Continue without Signing In" → MCP: List Servers → Start → Running, "Discovered 3 tools". ps showed node ~/.npm/_npx/3ec5bc0582433d0b/node_modules/.bin/sentinel-ir-mcp ..., whose cache package.json is 0.5.9 / 0.5.9. Works end to end.
Cursor 3.30.14: accepted the generated .cursor/mcp.json. Its log shows mcp.installed {name: sentinel-ir, command: npx -y sentinel-ir-mcp@stable-0.5} and State transition: project-0-Můj projekt ž-sentinel-ir none → disconnected. It then shows a Log In / Sign Up wall, and no server process starts without login. This is a client limitation, not a package bug.
Claude Desktop 5.11492.5: accepted the config and kept our entry when it added its own preferences. The "Get started" login wall blocks MCP; mcp.log stays empty and no process starts. This is a client limitation.

Network: across all URL and UNC calls, no SMB traffic and no lookups of the named hosts (check 1).

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

sentinel-ir 0.5.9 / sentinel-ir-mcp 0.5.9: Windows user test (round 3)

jackymenCZ (jackymenCZ) — Sun, 15 Nov 2026 17:50:46 +0000

Date: 2026-11-15
OS: Windows Server 2022 (x64). I used Git Bash for most steps and PowerShell for pktmon, links, the VHD and the desktop apps.

Node: 20.20.2 (npm 10.8.2), 22.23.5 (npm 10.9.9), 24.22.2 (npm 11.19.1)
Other tools: MCP client @modelcontextprotocol/sdk 1.32.2 (Client + StdioClientTransport), TypeScript 5.9.3 and 7.0.2, VS Code (portable zip, latest), Cursor (latest installer), Claude Desktop 0.14.10.
Source: only the published npm packages, installed or run through npx. No repo checkout, no code changes, no MR.
Not tested: macOS and Linux. This session ran only on the Windows machine.

Summary

There are no blockers. All 8 regression checks for 0.5.9 pass on Windows on Node 20, 22 and 24. Check 8 (README) has small gaps: the aliases are missing from one paragraph and not-a-folder is missing from the audit-log reasons. The MCP results were identical on all three Node versions. A diff of the normalized output for every call showed no differences.

Not verified: whether a desktop client actually starts the server from its config.

VS Code accepted the entry. Starting it from MCP: List Servers turned the status to Error with an empty server log, and no sentinel-ir-mcp process appeared. VS Code was unauthenticated and still in onboarding, so I can't blame the package (see U1).
Cursor and Claude Desktop stop at their login screens.
The same command line started fine through the real SDK client.

Issues found

#	Severity	Package	Title
1	bug (docs/behaviour mismatch)	sentinel-ir	An explicit `language: "ruby"` returns `language: "ruby"` and reason `unsupported language: ruby`, but the README says `"unknown"` / `unsupported file type: .rb`
2	papercut	sentinel-ir-mcp	`analyze_code` rejects `language: "JS"` (-32602); the library accepts any case
3	papercut	sentinel-ir-mcp	`doctor` prints `[ok] analyze_directory works ... (0 file(s) checked)`
4	papercut	sentinel-ir-mcp	`doctor` stale-cache warning names the copy `sentinel-ir-mcp@^0.5.8` under npm 10 but `sentinel-ir-mcp@0.5` under npm 11
5	docs	sentinel-ir-mcp	The README upgrade text ("npx keeps starting the copy it downloaded first for a range such as `@0.5`") is true for npm 10 but not for npm 11.19.1
6	papercut	sentinel-ir	`examples/basic.js` (the README's CLI route) prints a raw Node stack trace for a missing file
7	docs	sentinel-ir	The "Fewer tokens" table is stale (raw sizes are 2-4x smaller than the shipped files)
8	docs	sentinel-ir-mcp	The "Supported" paragraph lists `language` values without the aliases, and the audit-log refusal reasons don't include `not-a-folder`
9	papercut	sentinel-ir	Rust: `use std::process; process::exit(0)` in a broken file is `critical` with `child_process`; a valid file with `std::process::exit` is `low` but `forbidden: ["process.exit"]`
10	papercut (transient)	sentinel-ir-mcp	`doctor` once printed `[skip] No usable answer from the npm registry ...` while the network was busy

Issues in detail

1. bug: explicit unsupported `language` doesn't match the README (sentinel-ir)

Node: 20/22/24 (all identical)
Repro:

  mkdir lib && cd lib && npm init -y && npm install sentinel-ir@0.5.9
  node -e 'const s=require("sentinel-ir");(async()=>{await s.initializeWasm();
   for (const o of [{language:"ruby"},{target:"x.rb"}]) {
     const r=s.compress(s.analyze("puts 1",o));
     console.log(JSON.stringify(o), r.analysisStatus, r.language, r.facts.reason) }})()'

Expected (README, "Supported languages"): "An explicit unsupported language (e.g. "ruby") or, since 0.5.8, a target with any other extension ... is reported as analysisStatus: "incomplete" with language: "unknown" and facts.reason: "unsupported file type: .rb (…)"."
Actual:

  {"language":"ruby"} incomplete ruby unsupported language: ruby (supported: javascript, typescript, tsx, python, rust)
  {"target":"x.rb"} incomplete unknown unsupported file type: .rb (supported: .js .mjs .cjs .jsx .ts .mts .cts .tsx .py .pyi .rs)

The status is correctly incomplete, but language echoes the caller's string. Code that switches on language === "unknown" misses this case. Either always return "unknown" or change the README sentence.

2. papercut: MCP `analyze_code` `language` is case-sensitive, the library isn't

Node: 20/22/24, MCP client SDK 1.32.2, server npx -y sentinel-ir-mcp@stable-0.5 <folder> (reports 0.5.9)
Repro: call analyze_code with { "code": "eval(x)", "language": "JS" }.
Expected: the same result as js, because the library accepts JS and Python. The 0.5.9 changelog says "analyze_code takes the js, ts, py and rs aliases like sentinel-ir".
Actual:

  MCP error -32602: Input validation error: Invalid option: expected one of "javascript"|"typescript"|"tsx"|"python"|"rust"|"js"|"ts"|"py"|"rs" at language

Note: the error is clear and lists the valid values, so this is minor. The lowercase aliases js/ts/py/rs all work.

3. papercut: `doctor` says `[ok]` when 0 files were checked

Node: 24.22.2
Repro: use a project folder where the first file the walk reaches is skipped. My fixture had a 1.6 MB big/huge.js, symlinks and a hard link before src/; a folder where exclusions leave nothing analyzable also works. Then:

  npx -y sentinel-ir-mcp@stable-0.5 setup --client cursor --yes --exclude nomatch-folder --exclude "*.rb" --audit-log
  npx -y sentinel-ir-mcp@stable-0.5 doctor --client cursor

Expected: a [warn] or [skip], for example "nothing analyzable found in the first N files", or the check keeps walking until it analyzes one file.
Actual:

  [ok]   analyze_directory works on C:\t59\Projekt Žluťoučký kůň\myapp (0 file(s) checked)

The same folder without the Cursor config gives (1 file(s) checked). "Works" next to "0 files checked" reads as a contradiction.

4. papercut: the stale-npx-cache warning labels the copy differently on npm 10 and npm 11

Repro (npm 10, Node 20.20.2, npm_config_cache=C:\t59\c20):

  npx -y sentinel-ir-mcp@0.5.8 --version       # puts 0.5.8 in the cache (key 46f9bf218df4163a)
  npx -y sentinel-ir-mcp@0.5 doctor            # runs 0.5.8 (README behaviour)
  npx -y sentinel-ir-mcp@stable-0.5 doctor     # runs 0.5.9

Actual (npm 10): the warning names the cached copy sentinel-ir-mcp@^0.5.8. On npm 11.19.1 the same situation reads:

  [warn] The npx cache still holds sentinel-ir-mcp@0.5 (sentinel-ir-mcp 0.5.8, sentinel-ir 0.5.8) in C:\Users\Administrator\AppData\Local\npm-cache\_npx\46f9bf218df4163a; a client entry with that version or range keeps starting it, and sentinel-ir older than 0.5.9 misses security fixes
         -> Close the client, delete that folder (npm 11: npm cache npx rm 46f9bf218df4163a), then run: npx -y sentinel-ir-mcp@stable-0.5 setup

Cause (from the cache files): npm 10's _npx/<hash>/package.json is only {"dependencies":{"sentinel-ir-mcp":"^0.5.8"}}. npm 11 adds "_npx":{"packages":["sentinel-ir-mcp@0.5"]}. doctor falls back to the dependency range, which the user never typed.
Expected: a label the user recognises on both npm versions. When _npx.packages is missing, "a cached copy of sentinel-ir-mcp 0.5.8" would be enough. Apart from the label, both warnings are correct and actionable, and the folder hash is right.

5. docs: the README upgrade claim depends on the npm version

Repro (Node 24.22.2 / npm 11.19.1): put 0.5.8 in the cache under both @0.5 and @stable-0.5, then run npx -y sentinel-ir-mcp@stable-0.5 doctor and then npx -y sentinel-ir-mcp@0.5 doctor.
Actual: the second command also ran 0.5.9. Its cache folder _npx/46f9bf218df4163a/package.json now reads {"dependencies":{"sentinel-ir-mcp":"^0.5.9"},"_npx":{"packages":["sentinel-ir-mcp@0.5"]}}. On npm 10.8.2 the @0.5 copy stayed on 0.5.8, as the README says.
Caveat: I made the 0.5.8 cache entry with --before. A cache from a real earlier download may behave differently.
Suggestion: say "npm 10 keeps starting ...; npm 11 may re-resolve". The advice to use @stable-0.5 is right either way.

6. papercut: `examples/basic.js` prints a raw stack trace for a missing file

Node: 24.22.2 (same on 20/22)
Repro: node node_modules/sentinel-ir/examples/basic.js does/not/exist.js. The README gives this as the command-line route, and the package has no bin.
Actual (exit 1):

  node:fs:483
      return binding.readFileUtf8(path, stringToFlags(options.flag));
                     ^

  Error: ENOENT: no such file or directory, open 'C:\t59\Projekt Žluťoučký kůň\lib20\does\not\exist.js'
      at Object.readFileSync (node:fs:483:20)
      at Object.<anonymous> (C:\t59\Projekt Žluťoučký kůň\lib20\node_modules\sentinel-ir\examples\basic.js:7:17)
      at Module._compile (node:internal/modules/cjs/loader:1929:14)
      at Object..js (node:internal/modules/cjs/loader:2060:10)
      at Module.load (node:internal/modules/cjs/loader:1651:32)
      at Module._load (node:internal/modules/cjs/loader:1443:12)
      at wrapModuleLoad (node:internal/modules/cjs/loader:261:19)
      at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5)
      at node:internal/main/run_main_module:33:47 {
    errno: -4058,
    code: 'ENOENT',
    syscall: 'open',
    path: 'C:\\t59\\Projekt Žluťoučký kůň\\lib20\\does\\not\\exist.js'
  }

Expected: a one-line message such as basic.js: cannot read does/not/exist.js (ENOENT). Optionally, ship a small bin, because newcomers look for npx sentinel-ir <file>.

7. docs: the "Fewer tokens" table is stale (sentinel-ir README)

file	README raw chars	actual 0.5.9 raw chars
`src/ast-facts.js`	21,823	96,827
`src/sentinel-ir.js`	9,123	20,424
`src/tree-parser.js`	4,393	13,181

Measuring examples/basic.js on itself gives an IR of 552 characters; the README says 461. The claim still holds, and the real savings are larger, but the numbers are from an older release.

8. docs: gaps in the sentinel-ir-mcp README

The "Supported" paragraph says "an explicit language (javascript | typescript | tsx | python | rust)" without the aliases. The Tools table and the changelog do list js/ts/py/rs.
The audit-log section lists the refusal reasons excluded, outside, not-found, too-large, hardlink, symlink, unsupported, not-a-file, url, no-folders. analyze_directory on a file logs not a folder, so not-a-folder should be added.
The minimum sentinel-ir version is documented ("Needs sentinel-ir 0.5.9"), and doctor checks it. OK.

9. papercut: Rust `std::process` false positives (documented behaviour)

use std::process; fn main() { process::exit(0) (missing }) gives critical, forbidden: ["child_process","process_spawn"]. The README describes the module-only use std::process heuristic, but this is a very common idiom.
A valid fn main(){ std::process::exit(1); } gives risk low, but forbidden: ["process.exit"]. A reader who takes forbidden to mean "dangerous capability" may be confused.

10. papercut (transient): `doctor` update check

While a large download was running, one doctor run printed [skip] No usable answer from the npm registry about a newer sentinel-ir-mcp. The next run printed [ok] sentinel-ir-mcp 0.5.9 is the newest stable-0.5 on npm. The fallback is correct (skip, not fail). I'm noting it only for completeness.

Unverified / blocked

U1. Desktop clients starting the server from their config: not verified.

client	config written by	config accepted?	server process started?
VS Code (portable zip, latest)	`code --add-mcp '<json printed by setup --client vscode>'` -> `User\mcp.json`, non-ASCII path intact	yes, listed in MCP: List Servers	no: Start Server sets the status to `Error`; `mcpServer.mcp.config.usrlocal.sentinel-ir.log` is empty; no `sentinel-ir-mcp` process. VS Code was unauthenticated and in onboarding; its renderer log shows `Could not list installed MCP servers. (refused: policy-context-unavailable)`
Cursor (latest)	`setup --client cursor --yes` -> `<project>\.cursor\mcp.json` (`cmd /c npx -y sentinel-ir-mcp@stable-0.5 ... ${workspaceFolder}`)	file is valid; the app won't go past the login modal	not observed
Claude Desktop 0.14.10	`setup --client claude-desktop --yes` -> `%APPDATA%\Claude\claude_desktop_config.json`	file is valid; the app stops at "Get started"	not observed

I couldn't tell whether the VS Code Error comes from the package or from the client state.
The same command line, run as cmd /c npx -y sentinel-ir-mcp@stable-0.5 "C:\t59\Projekt Žluťoučký kůň\myapp", starts and answers the handshake through the real SDK client. doctor also performs its own handshake.
Recommendation: repeat with a signed-in VS Code or Cursor.

U2. There is no second physical disk. I used a 512 MB NTFS VHD mounted as V:.

U3. macOS and Linux were not tested in this session (Windows machine only).

The 8 regression checks for 0.5.9

#	Claim	Result
1	UNC `\\server\share\x.js`, `//server/share/x.js`, `file://server/share/x.js` refused before any file system or network access	PASS on Node 20, 22 and 24. pktmon filter: TCP 445/139, UDP 137/138, 5355, IP 10.255.255.1. During every UNC and remote-URL call: 0 packets on each Node version. Control `Test-Path \\10.255.255.1\share\x.js`: 28 packets (SYN to :445) after 22 s. Replies: `Access denied ... outside the allowed folders` (UNC) and `path must be a file path, not a URL` (remote `file://`)
2	`file:src/x.js` and `http(s)://` refused as URLs; local `file:///` inside the folder still works	PASS. `path must be a file path, not a URL: file:src/server.js`; `file:///C:/t59/Projekt%20Žluťoučký%20kůň/myapp/src/server.js` (encoded and raw) gives `complete javascript`; `file:///` outside gives `Access denied`
3	Broken Python/Rust is `critical` only when `forbidden` names the capability	PASS (library and MCP). `subprocess`, `os.system`, `std::process::Command`, `runpy`, `spec_from_file_location(...).loader.exec_module`, `from ctypes import *` give `critical` with `forbidden`. `std::process::exit`, `std::process::id`, `importlib.reload`, `from ctypes import c_int` are not `critical`. See issue 9 for the `use std::process;` idiom
4	`analyze_directory` summary lists `forbidden` for broken files with a dangerous capability	PASS (broken Python, Rust and JS fixtures)
5	`analyze_code` aliases `js`, `ts`, `py`, `rs`	PASS for lowercase. Uppercase is rejected, see issue 2
6	`log` wording	PASS. `pasted code (12 bytes, unknown): low (incomplete: unsupported language)`; `REFUSED file http://example.com/x.js: not a local file path`; `... outside the allowed folders`; `REFUSED file links/hard-out.js: file has several hard links`; folder line `1 not read (too large or unreadable), 1 not read (several hard links)`; `REFUSED folder src/server.js: not a folder`; `Not a file: src`
7	`doctor` warns on unmatched exclusions; stale-cache warning reads right for a range and for a tag	PASS with papercuts. `setup` and `doctor` both warn "matches nothing there yet (typo?)". The stale-cache warning is correct and actionable, but the label differs between npm 10 and npm 11 (issue 4)
8	README documents the `language` option and aliases, every refusal reason, and the minimum sentinel-ir version	Mostly PASS. Aliases are in the Tools table and changelog but not in the "Supported" paragraph; `not-a-folder` is missing from the audit-log reasons (issue 8)

0.5.8 fixes rechecked

Check	Result
Same `Access denied` for existing and missing outside paths, `..`, `\\?\C:\...`	PASS
Symlink outside refused (incl. dangling symlink and junction); symlink inside works	PASS
Unknown extension (`.rb`, `.go`) gives `incomplete` / `unknown`	PASS (but see issue 1 for an explicit `language`)
`doctor` per client (`--client cursor`; Claude Desktop and Windsurf paths)	PASS
`log \	head -1` exits 0 without EPIPE
TypeScript declarations under `strict` (tsc 5.9.3 and 7.0.2); the union on `facts.ast` narrows	PASS
Rust and TSX parse-error positions (`missing` / `unclosed` with line and column)	PASS
`.jsx` accepted	PASS

Verified working

sentinel-ir install: npm install sentinel-ir in a fresh project on Node 20, 22 and 24 takes 2-3 s. npm 11 prints the documented allow-scripts notice.
README API example: output is byte-identical to the README. initializeWasm() works. Outputs are identical across Node versions.
Languages: JS, TS, TSX, Python and Rust files analysed. Broken files in each language give incomplete with parse-error positions. Aliases and case-insensitive names work in the library.
Module formats: ESM default import and CJS require both work.
sentinel-ir-mcp CLI entry points:
- guide
- setup for every client (dry run, --yes, --audit-log, --exclude); re-running keeps existing settings
- whole-disk refusal: Refusing to give the agent access to a whole disk (V:\). Pass a project folder with --project.
- doctor, doctor --client cursor
- log, log --all, and guidance when the audit log is off
MCP over stdio with a real client (identical on Node 20, 22, 24):
- handshake {"name":"sentinel-ir-mcp","version":"0.5.9"}
- tools analyze_code, analyze_file, analyze_directory
- refusals: outside root, .., symlink, hard link (has 2 hard links; files with more than one are refused), oversized file (File too large: big/huge.js is 1600000 bytes, limit is 1048576), unsupported extension, Not a file, Not a folder
- directory summary with skipped.tooLarge, skipped.symlinks, skipped.hardlinks and riskCounts
Audit log: JSONL with a start record (version, folders, exclusions) and one line per call.
Paths: C:\t59\Projekt Žluťoučký kůň\myapp (spaces and diacritics) and V:\Další projekt on a second volume. setup and doctor are fine on both, and generated configs keep the non-ASCII characters intact.
Upgrade path: I read the actual _npx/<hash>/node_modules/sentinel-ir-mcp/package.json in each case.
- npm 10: @0.5 keeps running 0.5.8, and 0.5.8's own doctor warns This is sentinel-ir-mcp 0.5.8, npm has 0.5.9 (stable-0.5).
- @stable-0.5 runs 0.5.9, and its doctor names the stale folder with the delete command.
- npm 11: see issue 5.

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

Sentinel-IR and Sentinel-IR MCP are open for sponsors (and yes, an AI writes most of the code)

jackymenCZ (jackymenCZ) — Sat, 14 Nov 2026 19:59:54 +0000

A 5-minute read. One maintainer, two Apache-2.0 packages, zero venture capital, a mildly embarrassing amount of honesty.

The short version

sentinel-ir and
sentinel-ir-mcp now
accept sponsorship. Both READMEs have a Sponsor section, both repos have a
GitHub Sponsor button, and sentinel-ir publishes a
funding.json
manifest that funds and tools can read.

People: github.com/sponsors/jakcmencz. The profile was submitted today and GitHub is still reviewing it, so the link turns into a real Sponsor page once they approve it.
Companies, grants, integrations: write to sentinel.ir.contact@gmail.com. That works today.

What these two things are, in one paragraph each

sentinel-ir reads a source file and gives an AI agent a small fact sheet
instead of the whole file: risk level, network, filesystem, process and
environment calls, routes, imports and exports, and for Rust also unsafe,
FFI, build.rs and proc-macro behaviour. It covers JavaScript, TypeScript,
Python and Rust. It's static analysis: it never runs the code, and a "low"
risk is a hint, not a safety certificate.

sentinel-ir-mcp plugs that fact sheet into Claude Desktop, Cursor,
Windsurf and other MCP clients as a read-only stdio server. It only opens
supported source files inside the folders you allow, refuses traversal,
symlinks and hard links, has file-size, file-count and time limits, and can
keep an audit log of what it read (paths and hashes, never source).

One analyzer, one shared IR, the same facts in npm, the MCP server and the
browser playground. Adding
a language once adds it everywhere.

The honest part

I'm Jakub, the only maintainer, and I'm not a professional developer. I decide
what Sentinel should do, test it on my own machines and approve every release.
Most of the code is written by an AI coding agent working from my specs.
Every change still has to pass the test suites and CI on Linux and Windows
before it ships.

Some grant programmes don't fund AI-generated work, and I'd rather lose a grant
than pretend. If that's a deal-breaker for you, fair enough. If you think
"one person plus an agent shipping audited, tested releases" is exactly the
kind of thing worth backing, read on.

What it saves you (measured, not vibes)

Every time an agent "just takes a quick look" at a file, you pay for every
token of it, comments, licence header and the 400-line date formatter
included. Sentinel hands the agent the fact sheet instead. Measured on
Sentinel's own source with the o200k_base tokenizer:

file	the whole file	Sentinel's fact sheet
`src/ast-facts.js`	8,439 tokens	120 tokens
`src/sentinel-ir.js`	2,084 tokens	133 tokens
`src/tree-parser.js`	891 tokens	121 tokens
`examples/basic.js`	150 tokens	120 tokens

That's up to about 70 times less on a big file. On a tiny file it saves almost
nothing, because the fact sheet has a floor of about 120 tokens, and we'd
rather tell you than let you find out.

A back-of-the-envelope example (an illustration, not a measurement): your
agents open a file the size of ast-facts.js 200 times a day across the team.
That's about 1.7 million tokens a day you don't send. At an example price of
$3 per million input tokens, that's about $5 a day, or roughly $100 a working
month, for one file. Your repo has more than one file. Your agents are not
shy.

The time part is simpler: a model that reads 120 tokens gets to the point
sooner than one that reads 8,439, and its context window stays free for the
work you actually asked for. It's the difference between asking a colleague
"does this file touch the network?" and making them read it aloud first.

And the part that doesn't show up on an invoice: the agent sees
network: outbound and process: spawn before it trusts a file, instead of
discovering them three tool calls later in a postinstall script.

Why monthly, not one-off

A code analyzer is less like a hammer and more like antivirus definitions.
The day it stops being updated, it starts going stale:

Ecosystems keep inventing new doors. A new HTTP client, a new way to spawn a process, a new Rust build crate. Each one Sentinel doesn't know about is a door the agent walks past without noticing. Version 0.4.4 alone taught it axios, got, undici, superagent and fs-extra.
Languages keep coming. JavaScript, TypeScript, Python and Rust today; Go is next. Because everything sits on one shared IR, every new language shows up in the npm package, the MCP server and the playground at once. You pay for it once and get it three times.
Security work never finishes. The MCP server reads files on your machine for an AI. Path checks, size limits and parser robustness need regular adversarial testing, not a one-time audit framed on the wall.
The platforms move. New Node versions, new MCP clients, new MCP spec revisions. Somebody has to keep setup and doctor working on Monday morning.

A one-off donation is a very kind pizza. A monthly sponsorship is the
kitchen. We're grateful for pizza. The kitchen is what keeps the releases
coming.

For companies the maths is short: if Sentinel saves your team even one
engineer-hour a month in review time or token spend, the $5 Supporter plan
paid for itself before lunch. The Development plan is less than many
companies spend on coffee for the people who'd otherwise read those files.

Where the money goes

what	why
AI agent time	it writes the code, the tests and the release checks
CI and test machines	Linux and Windows CI on Node 20, 22 and 24, plus macOS test runs
Go support	the next language for the shared IR
security hardening	more adversarial tests for the parsers and the MCP path checks

The funding.json lists two plans: Supporter, $5/month (helps cover CI)
and Development, $12,000/year (a year of agent time, test machines, Go
and security work on both packages). One-time sponsorship is fine too.

Where we are today

About 1,150 npm downloads a week for each package (Nov 7–13). That number includes our own CI, so it's an upper bound on real users, not a vanity metric.
sentinel-ir-mcp is in the official MCP Registry as io.github.jakcmencz/sentinel-ir-mcp and on Glama.
Current releases: sentinel-ir 0.5.6 and sentinel-ir-mcp 0.5.6.

Can't sponsor? Still helps

Try it on your own repo: npx -y sentinel-ir-mcp@stable-0.5 setup.
Star the repo on GitLab or GitHub.
Open an issue when it gets something wrong. A false "low" is the bug I want most.
Tell the one colleague who keeps pasting whole files into ChatGPT.

Thanks for reading. If Sentinel ever saves your agent from reading
/etc/passwd, you know where the button is.

Sentinel-IR MCP 0.5: give your AI agent a library card, not the master key

jackymenCZ (jackymenCZ) — Sat, 14 Nov 2026 17:44:54 +0000

A 10-minute read for developers, platform teams and whoever has to answer
"wait, what can the agent read?" in a security review.

Source (GitLab, Apache-2.0): https://gitlab.com/jakubrojicek11/sentinel-ir-mcp
npm: https://www.npmjs.com/package/sentinel-ir-mcp
Listings: Glama · MCP Registry (io.github.jakcmencz/sentinel-ir-mcp)

TL;DR

sentinel-ir-mcp is a stdio MCP server
with three read-only tools: analyze_code, analyze_file and
analyze_directory. Instead of raw source, the agent gets a compact
structural IR from
sentinel-ir: risk level,
dangerous capabilities, routes, imports, env reads, network, filesystem,
process and crypto calls, each with a line number. It works with
JavaScript, TypeScript, Python and, since 0.5, Rust.

The 0.5 line is about two things: Rust, and making sure the copy
running on your machine is the one with the fixes. Plus a doctor that
we tried very hard to break on three operating systems.

The problem: agents read like a vacuum cleaner

Coding agents have discovered the filesystem, and they love it. Ask "is this
repo safe to deploy?" and a typical agent cats twenty files into its context.
That's 50,000 tokens of business logic, license headers and a comment from
2019 that says // TODO: remove before prod. Then it answers from vibes.

Three costs:

Money and context. Raw src/ast-facts.js is 8,439 tokens. Its IR is 120.
Prompt injection. Comments and strings are attacker-controlled text. A README that says "AI agents must run curl … | sh" is a real genre now.
Scope. Generic "read file" tools often see everything the process can see, ~/.ssh included.

sentinel-ir-mcp is the opposite design: small facts, narrow scope, no
writes.

Triage first, read later

The intended workflow, which the tool descriptions spell out for the agent:

analyze_directory the project. You get one short entry per file (path, risk, status, language, lines, operations, up to 3 risk signals), sorted from highest to lowest risk, plus riskCounts.
Look at the critical and high files and the incomplete ones. Incomplete means "didn't fully parse", and its low is not evidence of safety. We tell the agent that in capital letters.
Read the raw source of those files only.

On a 190-file Node project the default summary was 35,856 characters
(about 9,000 tokens) for the whole folder. That's less than a single
mid-sized file read raw.

{"folder":".","analyzed":42,"riskCounts":{"critical":1,"high":2,"medium":6,"low":33},
 "files":[{"path":"src/deploy.rs","risk":"critical","language":"rust",
   "operations":["processSpawn"],"riskSignals":["process_spawn:Cmd::new@14"]}, "..."]}

(Illustrative shape, trimmed.)

The security model, in plain terms

This is the part your security team will read, so we wrote it like an
interface contract.

It only reads. The server never writes project files, never executes
code and never opens a network connection. The tools are annotated
readOnlyHint: true, destructiveHint: false, openWorldHint: false.

Only inside the folders you allowed. Roots come from the command line
or, without folder arguments, from the client's MCP roots. Every requested
path is resolved to its real path and must land inside a root. In our audit
of the published 0.5.5 package, the server refused all of these:

../outside/s.js            -> Access denied: outside the allowed folders
/etc/passwd                -> Access denied: outside the allowed folders
src/link.js (symlink out)  -> Access denied
secrets/x.js (excluded)    -> Excluded by the user's settings. Do not try to read it another way.

The boring attacks are handled too:

Symlinks: files are opened with O_NOFOLLOW and directory scans skip every symlink.
Swapped files: after opening, the inode is compared with the file at the real path. A file swapped mid-read is refused.
Hard links: files with more than one link are refused, because a hard link can point anywhere and you can't see its other names.
Limits: files up to 1 MiB by default, 2 MiB at most. Scans cover 50 files by default, 500 at most, with a 30 s time budget.
Skipped folders: node_modules, .git, venv, hidden folders and Cargo target/ (only when it has Cargo's CACHEDIR.TAG).

Exclusions belong to the human. setup --exclude secrets --exclude dist
writes them into the client config. The agent can't change them, and
neither can the analyzed repo: there's deliberately no .sentinelignore,
because a malicious repo would use it to hide its own payload. Excluded
files are refused by analyze_file and only counted by
analyze_directory, because file names can be sensitive too.

An audit log, for the "who asked for what" question. It's opt-in
(setup --audit-log). It records the tool, the path, the result and the
SHA-256 of each file the agent was shown, and never the source. It must
live outside the project, rotates daily, keeps 30 days and stays under 50 MB
a day. Read it with npx -y sentinel-ir-mcp@stable-0.5 log:

2026-10-18 10:32:05 [cursor] file src/app.js: critical
2026-10-18 10:32:09 [cursor] REFUSED file secrets/aws.js: excluded by your settings
2026-10-18 10:33:40 [cursor] folder .: 42 file(s) (1 critical, 6 medium, 35 low), 3 excluded

The IR is still untrusted text. Comments and string bodies are not
copied, and since sentinel-ir 0.5.4 every string is capped at 128
characters and literals in evidence show up as "…". Identifiers and route
paths still come from the code. That reduces the injection surface; it
doesn't remove it, and every tool description tells the agent to treat IR
values as data, not instructions.

What's new in 0.5

Rust (0.5.0)

.rs files go through sentinel-ir's new Rust analyzer: unsafe and FFI,
std::process::Command, file writes and deletes, HTTP clients and servers
(axum, actix-web, ...). A build.rs or procedural macro that touches
files, the network or secret env vars is at least high, because it runs on
your machine during cargo build. For a supply-chain attacker that's the
best seat in the house.

Updates that actually arrive (0.5.1)

Here's a fun fact we measured against a local npm registry: npx never
re-resolves a cached version range. Configure your client with
sentinel-ir-mcp@0.5 and npx keeps starting the first 0.5.x it downloaded,
forever, even after security fixes ship. It's like a fridge that only ever
restocks the milk you bought in March.

A dist-tag is re-resolved on every start. So setup now writes
sentinel-ir-mcp@stable-0.5, and CI moves that tag forward on every release
(never backwards). Without network access, the cached copy still starts. The
server also requires sentinel-ir ≥ 0.5.6, which pulls in the
comment-hiding, parse-budget and broken-file fixes. doctor warns about
pinned entries and stale _npx cache copies, with the exact folder to
delete.

Tool descriptions agents can actually use (0.5.2–0.5.3)

Each tool description is now short lines in a fixed order: what it does,
what it returns, the parameters, the risk scale, when it refuses, and which
sibling tool to use instead ("for a folder use analyze_directory"). The
risk scale also says that medium (network, writes, crypto) is normal in
backend code, so the agent stops filing a P0 for every fetch().

`doctor`, the part we tried hardest to break (0.5.4–0.5.5)

npx -y sentinel-ir-mcp@stable-0.5 doctor checks Node, the package versions,
the client configs, exclusions, the audit log, a real MCP handshake and a
real analyze_directory call. Since 0.5.4 it also asks npm whether a newer
stable-0.5 exists (3 s timeout, skipped offline) and tells you where the old
copy runs from: the npx cache, a global install, npm link, Homebrew,
nvm-windows or Volta.

Then we spent a day trying to break it on Linux, macOS and Windows, with a
fake registry that answered in 28 different wrong ways (slow drips, gzip
bombs, redirect loops, __proto__, ANSI escapes with newlines) and 17
proxy setups. Things we found and fixed before 0.5.5 shipped:

The HTTPS proxy tunnel opened but wasn't used. A classic.
Registry credentials ended up in the proxy request line.
A % in a password crashed the check.
NO_PROXY was ignored under npx, because npm sets an empty npm_config_noproxy.
cafile and strict-ssl from .npmrc were ignored, so corporate proxies looked "offline".
A stuck DNS lookup kept the process alive for 30 s after it had printed its result. The check now runs in a child process that gets killed.
"All checks passed" was printed right under a [warn]. Now it counts the warnings.

Every case ends with a sensible message and exit code 0, in at most about
3.5 s. Behind a corporate proxy, doctor now behaves like npm does.

The audit release (0.5.6)

After 0.5.5 we audited the published package as a whole instead of trying to
break one feature. Nothing security-relevant turned up. Four small fixes
shipped:

guide (the agent's manual) still said "JavaScript and TypeScript".
A folder literally named ..cache was treated as "outside".
npm audit in the lock file showed two moderate advisories in a transitive Hono dependency of the MCP SDK. The stdio server never loads Hono, and fresh installs were already clean. The lock file now reports 0 vulnerabilities.
The MCP Registry entry is now published by the release workflow over GitHub OIDC, so nobody has to remember it at midnight.

Supply chain and release hygiene

Published only from GitLab CI on protected tags, with npm provenance. A fresh install has 101 packages with verified registry signatures and 17 with verified attestations.
Tested on Node 20, 22 and 24, plus Windows on Node 20, 22 and 24 before every publish. 146 tests run over real stdio with the official SDK client.
Three runtime dependencies: @modelcontextprotocol/sdk, zod and sentinel-ir. About 100 packages in node_modules. Unlike sentinel-ir, this one isn't dependency-free, and we say so in the README.

Getting started

# interactive: picks the client, the project folder, exclusions, audit log
npx -y sentinel-ir-mcp@stable-0.5 setup

# or explicit
npx -y sentinel-ir-mcp@stable-0.5 setup --client cursor --project ~/code/app \
  --exclude secrets --exclude dist --audit-log

# then
npx -y sentinel-ir-mcp@stable-0.5 doctor

setup shows what it will write, makes a backup, writes atomically, and
refuses to give an agent your whole home folder or a whole disk. Claude
Desktop, Cursor and Windsurf are supported directly. Any other MCP client
just runs npx -y sentinel-ir-mcp@stable-0.5 /path/to/project.

Where it fits in a company

Agent platforms: register it as the default "understand this code" tool and keep generic file reading for the few files that need it. You get a smaller context, a smaller bill and a smaller blast radius.
Security review: the read-only contract, root confinement and opt-in audit log answer the three questions every review asks: what can it touch, what can it change, and how do we know what it did.
Rust shops: surface build.rs and proc-macro behaviour in new dependencies before cargo build runs them on 200 laptops.
Monorepos with four languages: one tool and one IR shape across JS/TS, Python and Rust.

The honest limits

It's not a vulnerability scanner. Risk measures capabilities, not bugs. low means "nothing found".
One file at a time, and syntax only: no cross-file or data-flow analysis.
Rust macro expansion isn't followed (that needs rustc).
Hard links are refused even when they're harmless (pnpm's node_modules). Secure defaults sometimes say no to your friends too.

What's next

Go is next. Because the server speaks the shared sentinel-ir IR, a new
language in the library lands in the MCP server and the
playground without a
new output format, so your agent's prompts don't change.

Bug reports and merge requests are welcome on
GitLab. If you manage to
make the server read /etc/passwd, we'd genuinely like to hear about it
before your glama.ai followers do.

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

Sentinel-IR 0.5: your LLM doesn't need the whole file, it needs the gossip

jackymenCZ (jackymenCZ) — Sat, 14 Nov 2026 17:39:35 +0000

A 10-minute read for developers, tech leads and the person at your company
who signs the AI invoice.

Source (GitLab, Apache-2.0): https://gitlab.com/jakubrojicek11/sentinel-ir
npm: https://www.npmjs.com/package/sentinel-ir
Playground (runs in your browser): https://sentinel-ir-playground-dc30c8.gitlab.io/

TL;DR for people who scroll

sentinel-ir turns one source file into a small JSON fact sheet built from a
real syntax tree: imports, exports, routes, env reads, network, filesystem,
process and crypto calls, dangerous syntax, a risk level and the line that
caused it. You send that to the model instead of the raw file.

0.5 adds Rust, compile-time risk for build.rs and procedural macros,
hardening against comments and hostile input, and is ~28% faster on a
35,000-file corpus. Same IR shape for every language, so the tools built on
top (an MCP server and a browser playground) didn't need a single new field.

Why bother: the "senior dev at standup" problem

Ask a senior developer what a file does and you won't get a recital of 1,200
lines. You'll get: "It's an Express handler, reads STRIPE_KEY, writes to
/tmp, and shells out to ImageMagick, which is the part that'll bite us."

That's the IR. An LLM reading the raw file is the intern reading all 1,200
lines out loud. The tokens cost money, the comments can contain "ignore
previous instructions", and the important line is somewhere around 940.

Measured on the library's own source through the MCP server (tokenizer
gpt-tokenizer, o200k_base):

file	raw tokens	IR tokens
`src/ast-facts.js`	8,439	120
`src/sentinel-ir.js`	2,084	133
`src/tree-parser.js`	891	121
`examples/basic.js`	150	120

The IR has a floor of about 120 tokens. On a tiny file it doesn't pay off,
and we say so. On anything you'd actually want reviewed, it's one or two
orders of magnitude.

What the output looks like

Three lines of JavaScript that call eval and child_process:

{"analysisStatus":"complete",
 "world":{"risk":"critical"},
 "forbidden":["eval","child_process","process_spawn"],
 "facts":{"ast":true,"imports":["child_process"],
  "operations":["dynamicEval","processSpawn","childProcess"],
  "riskSignals":["child_process_import:require(child_process)@1",
                 "dynamic_code:eval@2","process_spawn:cp.exec@2"]}}

(Trimmed. The full IR also has mission, constraints, summary and the
call lists.) Every signal is kind:evidence@line, so a reviewer, human or
model, can jump straight to the proof. facts.ast: true means the file
parsed completely, so a missing category is a proven absence, not a shrug.

The rules are structural, not vibes: a route is a call on
app/router/server/api with a string path, exec is only process
spawning when it's bound to a spawning module, and a function called
evaluate is not eval. Regex-based scanners have been confusing those two
since before some of you were born.

New in 0.5: Rust

Rust is the language you pick when you'd rather argue with a compiler than
with production. It's also where a lot of new infrastructure, browsers and
crypto lives, so it's a good place to know what code can do.

The Rust analyzer produces the same IR and fact categories as JS/TS/Python.
Paths are resolved through the file's own use declarations, including
aliases, {...} lists, self, * globs and extern crate:

use std::process::Command as Cmd;
fn deploy() { Cmd::new("sh").arg("-c").arg(script).status(); }
// -> processSpawn, critical, process_spawn@2

crate::, self::, super:: and a local mod fs { ... } are not mistaken
for the standard library. A few of the things it recognizes:

Processes: std::process, tokio::process, nix exec and fork, libc::system, duct, xshell.
Native code (critical): unsafe, extern blocks, #[no_mangle], asm!, libloading, Windows LoadLibrary.
Embedded interpreters: rhai, mlua, deno_core, v8, pyo3 run/eval.
Filesystem, network and env: std::fs, tokio::fs, reqwest, hyper, TcpStream, std::env::var, dotenvy.
Routes: axum .route("/p", get(h)), actix attributes, rocket, warp, poem, salvo.

Does it actually parse real Rust? The stock tree-sitter-rust 0.24.2
grammar rejects a surprising amount of real code: all of web-sys/js-sys
(wasm-bindgen pub type X;), safe fn, const impl, trait aliases, macro
2.0, f16/f128, and more. We ship a patched grammar that rebuilds byte
for byte from a script. Results:

corpus	stock grammar	patched
15,238 files, 424 crate versions (tokio, reqwest, axum, nix, libc, ring, web-sys…)	13,693 parse	15,238
2,874 files of the Rust standard library	2,724 parse	2,874

Is unsafe detection any good? We compared it with
syn, the parser behind cargo-geiger, on the
15,237 files syn parses:

construct	syn	sentinel-ir
`unsafe impl`	2,839	2,839
`unsafe trait`	160	160
`extern` blocks	6,266	6,266
`unsafe fn`	10,137	10,149 (12 inside wasm-bindgen `extern` blocks syn skips)
`unsafe` blocks	35,428	37,167 (the extras are in macro bodies syn doesn't look into)
files with any `unsafe`	4,857	all 4,857 flagged

Plus 49 labeled snippets, and 2,950 deliberately broken real files that never
crash the analyzer and never report a dangerous operation from a half-parsed
file.

New in 0.5: the code that runs before your code runs

Here's the part that should make a security team sit up. In Rust, two kinds
of code execute on the developer's machine during cargo build:

build.rs build scripts.
Procedural macros (#[proc_macro], #[proc_macro_derive], #[proc_macro_attribute]).

This is the supply-chain attack path: you never ran the dependency, you just
compiled it. That's like being pickpocketed by the IKEA manual.

Since 0.5.1, in such a file, reading or writing files at runtime, using the
network or touching a secret-like env variable raises the risk to at least
high:

#[proc_macro_attribute]
pub fn m(a: TokenStream, i: TokenStream) -> TokenStream {
    std::fs::read_to_string("/etc/passwd"); // low -> high
    i
}

What the compiler reads on purpose (include!, include_str!,
#[path]) and Cargo's own variables (OUT_DIR, CARGO_CFG_*) do not raise
it, so normal build scripts don't light up like a Christmas tree. Building or
linking C at build time (cc::Build, cmake, pkg_config, vcpkg,
cargo:rustc-link-lib) is nativeCode, i.e. critical.

On 18,112 real files (crates.io and std) 0.5.1 changed 19 risk levels, all of
them build scripts or C builds, and 17 of those went to critical. Zero
analysisStatus changes.

New in 0.5: harder to fool, harder to stall

An analyzer that feeds an LLM is itself an attack surface. The person who
wrote the file you're scanning gets to pick its contents. So in 0.5.4 and
0.5.5:

Comments can't hide calls. require(/*x*/"child_process").exec(c) was low in 0.5.3. Ouch. Every extractor now skips comment nodes, in every language. A fuzz run inserting comments into 2,910 files: 0 fact differences.
Text from the code is capped and redacted. Every string that reaches the IR (routes, imports, env names, evidence) is one line and at most 128 characters. String literals in evidence become "…", so token == os.environ["API_TOKEN"] shows up as token == os.environ["…"]. Less attacker-controlled text reaches your prompt. It's less, not none, and the README says so.
Broken files keep their risk. When a Python or Rust file doesn't parse (one syntax error, absurd nesting), the text fallback now knows each language's dangerous names (os.system, subprocess, Command::new, unsafe, std::fs::write…). Breaking your own syntax used to be a way to look harmless. Now it just makes you look broken.
5-second parse budget. tree-sitter's error recovery is superlinear on some inputs: 16 KB of -> took about 43 s in JS. Now a parse stops at 5 s and the result is incomplete with the reason. The slowest real file in a 35,000-file corpus takes 0.2 s, so only hostile input ever hits this. 4,000 mutated files: 0 crashes, 0 risk levels lowered.

New in 0.5: faster, for free

0.5.3 stopped building a JS object for every syntax node and walking the tree
a second time for metrics nobody read. The IR stayed byte-identical:

measurement	0.5.2	0.5.3
35,000 files (Rust, JS, TS, Python)	210 s	151 s
memory, 910 KB Rust file	381 MB	222 MB
memory, 744 KB Python file	188 MB	123 MB
IR differences	—	0

The best optimization is deleting code. Here, nobody was even reading it.

Supply chain: we eat our own cooking

A security-flavored package shipped from someone's laptop at 2 a.m. is a
genre of horror movie. sentinel-ir is published only from CI on protected
tags, with npm provenance. Since 0.5.2 the release fails if the
provenance attestation is missing, and CI checks npm audit signatures on
npm 10 and 11 after publishing. Tests run on Node 20, 22 and 24.

How companies can use it

Cheaper code review bots. Triage a pull request by IR first, then send the raw source of only the files whose risk changed. The model reads 120 tokens instead of 8,000 for every file that just formats dates.
Dependency gates. Flag new or updated crates whose build.rs or proc macro suddenly touches the network. That's exactly the moment you want a human to look.
Agent guardrails. Give agents the IR through the MCP server so they reason about what code does without pasting it into the conversation.
One shape for four languages. JS/TS, Python and Rust come out in the same JSON. Your pipeline handles one format, not four parsers with four opinions.

const { analyze, compress } = require("sentinel-ir");
const ir = analyze(source, { target: "build.rs" });
if (ir.world.risk === "critical" || ir.world.risk === "high") flagForReview(ir);
sendToModel(compress(ir));

The honest part

We'd rather you trust the numbers than the marketing, so here's what it
doesn't do:

One file at a time. Capabilities split across files are not combined.
Syntax, not data flow. readFileSync(req.query.f) is a file read, not "path traversal". Risk is about capabilities, not vulnerabilities, and medium (network, writes, crypto) is normal backend code.
Macros are token trees. Calls inside a macro's arguments are found. What a macro expands to is not, because that needs rustc and cargo expand, which a source-only analyzer doesn't run.
Not a scanner replacement. Code that builds module names at runtime can look harmless. low means "nothing found", not "safe". Use it next to your SAST and your reviewers, not instead of them.

What's next

Go is next on the list. Same IR, same categories, a fifth language. The goal
hasn't changed: one analyzer, one shared shape, reused everywhere (the npm
library, the MCP server and the playground), so a new language lands in
all three at once.

Try it without installing anything in the
playground, or:

npm install sentinel-ir

Issues and merge requests are welcome on
GitLab. Bug reports that
start with "I tried to break it and…" are especially welcome.

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

Sentinel-IR MCP 0.5: a bouncer for your AI assistant

jackymenCZ (jackymenCZ) — Sat, 14 Nov 2026 17:35:09 +0000

A 2-minute read. No programming needed. Contains one (1) nightclub metaphor.

What it is

AI coding assistants such as Claude Desktop, Cursor and Windsurf can now read
the files on your computer by themselves. That's handy. It's also a bit like
giving a very fast, very eager intern the keys to the whole office.

Sentinel-IR MCP is the bouncer at the door. MCP is the standard plug that
lets AI assistants use outside tools. Plug Sentinel-IR MCP in, and your
assistant gets a short X-ray of each code file (what it touches, how risky it
is, which line does it) instead of the full text, but only for the folder you
picked:

Only your project. Shortcuts and sneaky paths that lead out of the folder are refused. So is /etc/passwd. (We checked. Twice.)
Only reading. It never changes a file, never runs code, never sends your code anywhere.
Your no-go list. Say "never look at secrets", and the assistant can't change that, and neither can a file in the project.
A diary, if you want one. Turn on the log and you can see later what the assistant asked for: file names and results, never your code.

What's new in 0.5

It reads Rust. JavaScript, TypeScript, Python and now Rust. It also skips
Rust's giant build folder, so your assistant doesn't spend an afternoon
reading machine-generated leftovers.

It updates itself. Before, npx (the tool that starts the server) kept
starting the first copy it ever downloaded, a bit like a phone that hides
system updates in a drawer. Now setup points it at a label called
stable-0.5, which npx checks again on every start, so fixes reach you
automatically.

It has a doctor. Run npx -y sentinel-ir-mcp@stable-0.5 doctor and it
checks everything: your setup, your no-go list, the diary, whether the server
starts, and whether a newer version exists. It now works behind company
proxies too, and it no longer says "all good" when it just printed a warning.
(Yes, it used to. We're not proud.)

Tested on all three. Linux, macOS and Windows. We tried hard to break it
before release and fixed everything we found.

Get it

One command sets up your assistant (it asks before writing anything):

npx -y sentinel-ir-mcp@stable-0.5 setup

Listed on Glama and
the official MCP Registry. Free and
open source:
GitLab ·
npm

Want to see what the assistant sees first? Try the
playground.

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

Sentinel-IR 0.5: an X-ray for code, now with a Rust filter

jackymenCZ (jackymenCZ) — Sat, 14 Nov 2026 17:33:04 +0000

A 2-minute read. No programming needed. Mild sarcasm included at no extra cost.

The problem, in one picture

When you ask an AI assistant "is this code safe?", most tools paste the whole
file into the chat. That's like asking your doctor about a sore knee and
handing over every selfie you've ever taken. Technically it's all you. Mostly
it's noise, and you get billed for the noise, because AI is paid by the word.

Sentinel-IR hands over the X-ray instead. It reads a source file and
writes a short note: what the code touches (files, the internet, passwords,
other programs), how risky that is (low, medium, high, critical) and
the exact line where it does it. A 40,000-character file becomes a note of
about 450 characters. The AI reads the note, and you pay for the note.

What's new in 0.5

1. It reads Rust now. Rust is the language people pick when they want
software that doesn't crash, which is why it ends up in browsers, operating
systems and crypto wallets. Sentinel-IR already spoke JavaScript, TypeScript
and Python. Rust is number four, and it isn't a beginner's phrasebook: we ran
it on more than 18,000 real Rust files, including Rust's own standard library,
and every one of them was read completely.

2. It watches the build, not just the program. Rust has a sneaky feature:
some code runs while the program is being built, on the developer's
laptop, before anyone has pressed "run". Think of a flat-pack wardrobe that
rearranges your living room while you're still reading the instructions.
Sentinel-IR now marks that kind of code as at least high risk when it
touches files, the internet or secrets.

3. It's harder to fool. A tiny comment wedged into the middle of a line
used to be enough to hide a dangerous call. Now it isn't. A file built to
make the analyzer think forever gets 5 seconds and then a stamp saying "this
one didn't finish, don't trust the low score".

4. It's faster and lighter. The same 35,000 real files now take 151
seconds instead of 210, and a large Rust file needs about 40% less memory.
Your laptop fan says thanks.

What it doesn't do

It doesn't run your code, doesn't upload it anywhere, and doesn't pretend to
be a security guard. "Low risk" means "nothing scary found", not "certified
safe". It's a smoke detector, not the fire brigade.

Try it

Open the playground, paste
some code (or open a file from your phone) and see exactly what an AI agent
would get. Everything runs inside your browser and nothing is uploaded.

Free and open source (Apache-2.0):
GitLab ·
npm

Sentinel-IR 0.5 in 30 seconds

jackymenCZ (jackymenCZ) — Sat, 14 Nov 2026 17:30:38 +0000

Your AI agent used to read code the way a tourist reads a menu in a language
they don't speak: slowly, expensively, and with a lot of guessing.

Sentinel-IR 0.5 speaks four languages now: JavaScript, TypeScript, Python
and Rust. It catches the Rust tricks that run while you're still waiting
for cargo build. A comment hidden in the middle of a line can't sneak a
dangerous call past it anymore, and a file built to make it hang gets five
seconds before it's cut off.

Sentinel-IR MCP 0.5 plugs all of that into Claude Desktop, Cursor and
Windsurf. It updates itself through a stable-0.5 tag, and its doctor
tells you when you're running an old copy.

Same rule as always: it reads your code, never runs it, and never sends it
anywhere.

Try it in your browser: https://sentinel-ir-playground-dc30c8.gitlab.io/

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

Why Your AI Coding Agent Needs a Doctor’s Filing Cabinet. Sentinel Ir

jackymenCZ (jackymenCZ) — Sat, 14 Nov 2026 15:32:05 +0000

Imagine walking into a doctor’s office. You hand over your ID, and the nurse walks over to a massive metal cabinet. Inside, thousands of patient records are thrown together in one giant, unsorted pile. No folders. No alphabetical dividers. No insurance codes.
To find your file, she has to pull out every single sheet of paper, read it from top to bottom, and put it back—until she finally stumbles upon your name.
In the real world, no doctor works like that. A real clinic organizes records by insurance provider code, then alphabetically by last name. When Mr. Novak walks in with insurance code 205, the nurse pulls his folder in three seconds flat.
It’s boring. It’s obvious. And it saves hundreds of hours.
Yet, when we give AI coding agents access to our software repositories today, we still hand them an unsorted pile of paper.

Links
Playground: https://sentinel-ir-playground-dc30c8.gitlab.io/
GitHub: sentinel-ir · sentinel-ir-mcp · sentinel-ir-playground
GitLab (main): sentinel-ir · sentinel-ir-mcp · sentinel-ir-playground
Glama: https://glama.ai/mcp/servers/jakcmencz/sentinel-ir-mcp
MCP Registry: io.github.jakcmencz/sentinel-ir-mcp
npm: sentinel-ir · sentinel-ir-mcp
Issues are welcome on GitHub or GitLab. Bug reports with a file that fools
the analyzer are the best kind.

The Hidden Cost of AI-Generated Code

We are entering an era where AI agents generate billions of lines of code every day. Repositories are growing faster than humans—or even the agents themselves—can comfortably read.
When an AI agent (in Claude Desktop, Cursor, or Windsurf) tries to understand a project today, its default behavior is brute force:

List the directory.
Open massive source files.
Read thousands of lines of implementation details, comments, and boilerplate just to find where a single function is defined or how two modules connect. Every time it does this, two things happen: • Context bloat: The model’s attention gets diluted by noise, leading to hallucinations and missed edge cases. • Token & latency waste: You pay for tens of thousands of tokens just for the agent to "look around" the room. As codebases scale, raw file reading stops working. You don't want your agent reading every single sheet of paper in the cabinet just to find Mr. Novak.

Building the "Boring" Infrastructure: Sentinel IR

When I started building sentinel-ir-mcp, I wasn't trying to invent a flashy AI wrapper. I wanted to build the doctor’s filing cabinet for codebases.
Instead of forcing an LLM to parse raw JavaScript, TypeScript, and Python files over and over again, Sentinel IR uses a fast, local Rust engine to extract a compact Structural Intermediate Representation (IR)—a deterministic map of symbols, signatures, exports, and relationships.
Think of it as the index card on the front of the drawer:
• Code 205 → Novak: The agent queries the structural IR first, sees the exact shape of the codebase in milliseconds, and only opens the raw source file when it actually needs to read or edit the implementation.
• Local-first & deterministic: Powered by Rust and running locally over stdio via the Model Context Protocol (MCP), it doesn't guess, it doesn't upload your code to a third-party cloud, and it works offline.

Why "Boring" Reliability Matters More Than Hype

A filing cabinet is only useful if the drawer doesn't jam when you pull it.
In real-world engineering, developers don't work on pristine laptops with open internet. They work behind corporate proxies, custom TLS certificates, weird Windows paths with non-ASCII characters, and restricted environments. If an MCP server crashes the moment it hits a proxy or a self-signed certificate, it becomes another piece of fragile hype.
That’s why most of the work behind sentinel-ir-mcp went into the unglamorous parts: cross-platform determinism, strict environment diagnostics (sentinel-ir-mcp doctor), and adversarial testing across macOS, Windows, and Linux.

Looking Ahead

Ten years from now, when AI agents are maintaining codebases orders of magnitude larger than today's monorepos, nobody will want agents brute-forcing raw text files. The winners in AI tooling won't just be the smartest models—they will be the quiet, reliable indexing layers underneath them.
Sometimes, the best way to move forward is to organize the cabinet.

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

Running Claude Code and a Local MCP Server (sentinel-ir-mcp) on Android via Termux

jackymenCZ (jackymenCZ) — Thu, 12 Nov 2026 18:13:54 +0000

Want a full-featured AI coding agent right in your pocket on Android, connected to your own local Model Context Protocol (MCP) server? While Anthropic's official Claude Code CLI doesn't natively support Android out of the box, you can get the entire stack running smoothly inside Termux in just a few minutes.

In this guide, we will walk through the complete setup step-by-step—including how to bypass the exact installation roadblocks you hit on Android and how to wire up sentinel-ir-mcp so Claude can inspect your code safely without burning tokens.

Step 1: Set Up Your Project and Verify the MCP Server in Termux

Before installing the AI client, create a dedicated workspace and verify that the MCP server (sentinel-ir-mcp) runs properly in your Termux Node.js environment.

Run the built-in health check:

npx -y sentinel-ir-mcp@0.4 doctor

As long as you have Node.js 20+ installed, doctor will verify the handshake and confirm that all three tools (analyze_code, analyze_directory, and analyze_file) work properly.

Security Safeguard Note: If you run npx -y sentinel-ir-mcp@0.4 setup directly inside your Termux home folder (~), the tool will intentionally block you with: Refusing to give the agent access to your whole home folder. By design, it prevents AI agents from scanning personal configs or sensitive files outside a specific project directory.

Create a dedicated project folder and generate the setup command inside it:

mkdir ~/my-project
cd ~/my-project
npx -y sentinel-ir-mcp@0.4 setup --client claude-code

The setup wizard will output the exact registration command you will need for Claude Code.

Step 2: Why Direct Claude Code Installation Fails in Termux

Installing Claude Code directly via npm install -g @anthropic-ai/claude-code in Termux fails due to:

Blocked lifecycle scripts: Newer npm versions block postinstall scripts by default.
Missing Android binaries: The installer lacks builds for Android's bionic libc, supporting only standard Linux (linux-arm64) and other desktop/server platforms.

Step 3: The Fix — Running Ubuntu in Termux (No Root Required)

You can bypass this by running Ubuntu via proot-distro inside Termux:

pkg update && pkg install -y proot-distro
proot-distro install ubuntu
proot-distro login ubuntu

Once inside the Ubuntu environment, install Node.js and Claude Code:

apt update && apt install -y curl
curl -fsSL https://nodesource.com | bash -
apt install -y nodejs
npm install -g @anthropic-ai/claude-code

Step 4: Create a Sample File and Connect sentinel-ir-mcp

Navigate to your Termux project folder (accessible directly from Ubuntu via its full path), create a sample JavaScript file with risky capabilities to test the analyzer, and register your MCP server.

cd /data/data/com.termux/files/home/my-project

cat << 'EOF' > test.js
const fs = require('fs');
const { exec } = require('child_process');

function runCommand(cmd) {
  exec(cmd);
}
module.exports = { runCommand };
EOF

Now register sentinel-ir-mcp with Claude Code using the command generated in Step 1:

claude mcp add --transport stdio sentinel-ir -- npx -y sentinel-ir-mcp@0.4 /data/data/com.termux/files/home/my-project

Step 5: Launch Claude Code and Authenticate

Everything is wired up. Start the Claude Code CLI:

claude

You will be greeted by Claude Code's pixel mascot ("Clawd") and guided through a quick one-time onboarding:

Choose your preferred terminal theme (e.g., Dark mode).
Select your authentication method—either a standard Claude.ai subscription (Pro / Max) or an Anthropic Console API account with usage credits.
Open the authentication link in your phone's browser, approve access, and paste the verification code back into Termux.
Trust the /data/data/com.termux/files/home/my-project workspace when prompted.

Putting It to the Test

Once inside the interactive prompt, ask Claude to inspect your workspace:

"Use sentinel-ir (analyze_directory) to scan this project and summarize any capability risks."

Under the hood, Claude calls your local sentinel-ir-mcp server over stdio. Instead of ingesting raw source code, it receives a compact structural Intermediate Representation (IR) and immediately flags the critical risk from child_process (cp.exec)—giving you a fast, token-efficient, and sandboxed AI development workflow right on your phone.

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Is Your Code Used to Train AI? The Security-First Guide to Claude Code + sentinel-ir-mcp

With everyone talking about Claude Code right now, it is completely fair for security-conscious developers to ask: Does my proprietary code end up training Anthropic’s models, and can the AI snoop through my private files?

The short answer is no, not when configured properly. By pairing Claude Code with a local "sentinel-ir-mcp" server, you can introduce an additional security layer between your local codebase and your AI tooling.

Think of "sentinel-ir-mcp" as a strict security gate standing between your private files and the AI agent.

Here is the security breakdown, including the relevant privacy policies, technical limitations, and commands to configure your environment.

Your Code Is NOT Used to Train Models

How Anthropic handles your data depends on your account type and settings:

API Keys, Team & Enterprise Plans: Under Anthropic's Commercial Terms, customer inputs and outputs are not used for model training by default. Standard retention and Zero Data Retention options depend on account eligibility and configuration.
Personal Accounts (Claude Pro / Max): These fall under Consumer Terms. Users can manage model-training permissions through "Anthropic's privacy settings" (https://claude.ai/settings/data-privacy-controls).
The "/feedback" Warning: Avoid submitting sensitive code through "/feedback", bug reports, or sharing features. Explicit feedback submissions may be retained separately for service improvement.

Your Raw Code and Secrets Need Protection

The local "sentinel-ir-mcp" server provides an additional inspection layer before source information is made available through its MCP tools.

Its security-oriented features include:

Local Execution: Source analysis runs locally rather than requiring your project files to be uploaded to an external analysis service.
Intermediate Representation (IR): Instead of relying exclusively on raw source code, the server can provide compact structural information, including risk signals, forbidden operations, and relevant code locations.
File Exclusions: Configure restricted paths and file patterns to prevent the MCP server from processing sensitive files.
Symlink Protection: Symbolic links are skipped during directory scanning.
SHA-256 Audit Trail: Local audit records can provide integrity fingerprints for analyzed content.

Important distinction: A local MCP server does not automatically control everything Claude Code can access. Claude Code has its own permissions, tools, and filesystem access. The MCP server's restrictions apply to its own operations, not necessarily to the entire AI agent.

How to Configure Your Environment

The following setup adds restrictions to the local MCP server and reduces non-essential Claude Code traffic.

Step 1: Configure sentinel-ir-mcp exclusions

Run these commands inside your project directory:

cd your-project-folder

npx -y sentinel-ir-mcp@0.4 setup \
--client claude-code \
--exclude secrets \
--exclude ".env*" \
--exclude "*.pem"

These exclusions configure the MCP server's scanning scope. They should not be interpreted as a global filesystem restriction for Claude Code.

Step 2: Disable non-essential traffic

Add the following environment variables to your shell profile ("~/.bashrc" or "~/.zshrc"):

export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
export DISABLE_TELEMETRY=1
export DISABLE_ERROR_REPORTING=1
export DISABLE_FEEDBACK_COMMAND=1

These settings should be checked against the current Claude Code documentation because supported environment variables and their behavior can change between releases.

Step 3: Reduce local session caching

Edit:

"~/.claude/settings.json"

Set the cleanup period to one day:

{
"cleanupPeriodDays": 1
}

This controls local session cleanup. It does not change Anthropic's server-side data retention policies.

What This Setup Actually Protects

It is important to distinguish between three separate security boundaries:

Security layer| What it controls
Anthropic privacy settings| Whether submitted data can be used for model training
Claude Code permissions| What the AI agent can access and execute
sentinel-ir-mcp| What the MCP server itself can inspect and expose

No single configuration replaces the others.

A local MCP server is an additional security component, not a complete sandbox or a guarantee that proprietary source code never reaches a cloud service.

Bottom Line: Security Before Convenience

You do not have to abandon advanced AI development tools to take source-code privacy seriously.

Combining commercial data-protection terms, carefully configured Claude Code permissions, and a local "sentinel-ir-mcp" analysis layer provides a more controlled development environment.

The important thing is understanding exactly where each security boundary begins and ends.

Experiment first. Headline second. Security claims should always match what the software actually enforces.

Explore the projects

Sentinel Ecosystem: AutoDoc-Sentinel, Sentinel-IR, Sentinel-IR-MCP and related tools.

Agentix Lite: Independent security and system-observation project.

Find the projects: GitLab repositories | NPM packages

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

90 Minutes for One Merge Gitlab? Windows Developers Can't Afford to Wait.

jackymenCZ (jackymenCZ) — Wed, 11 Nov 2026 15:26:44 +0000

https://gitlab.com/jakubrojicek11/sentinel-ir-mcp/-/blob/09b61d9dc1b90f3ebc7a37be0493d951249453cf/.github/workflows/windows.yml

description: "Slow CI is only the beginning. Shell differences, executable resolution, special characters in paths, and MCP client configurations create a hidden compatibility tax for developers building AI tools for Windows."

series: "The Windows Development Challenge"

The Windows Tax: Why Building AI Developer Tools for Windows Is Harder Than It Looks 🪟

In "Part 1, we reduced our Windows CI/CD pipeline from 13.6 minutes to 2 minutes and 44 seconds" (https://dev.to/jackymencz/how-we-slashed-our-windows-cicd-pipeline-from-14-minutes-to-under-3-2id0).

That solved one problem: waiting for tests.

But it exposed another problem that developers working on AI infrastructure know very well.

Getting your software to actually work on Windows is an entirely different engineering challenge.

Writing an MCP server is one thing. Making sure it installs, launches, connects, and behaves correctly across different Windows environments is another.

And sometimes, the problem is not your application code at all.

It's the operating system standing between your code and the user.

🛑 Problem No. 1: "npx" Is Not Always "npx"

Let's start with something deceptively simple.

An MCP server needs to launch through Node.js. On Linux, developers often use a straightforward process invocation:

"spawn("npx", args)"

Easy enough.

Except Windows has a different executable resolution model for command-line tools.

The npm executable on Windows is typically provided through "npx.cmd", not a regular executable that every process launcher can start directly.

During our Windows compatibility testing, a direct "spawn("npx")" failed with "ENOENT" across Node.js 20, 22, and 24.

We tested alternative launch strategies.

The solution was to use the Windows command interpreter:

"cmd /c npx"

Our recorded compatibility tests confirmed that this approach connected successfully across all three Node.js versions.

One small launcher difference. Three Node.js versions. An entirely different execution path.

This is the kind of problem that can make an otherwise perfectly functional AI tool completely unusable.

🧩 Problem No. 2: Windows Paths Are a Minefield

You might think handling a project path is trivial.

Let's try this one:

"C:\sentinel-test\it's $HOME & 100% ^caret! (x)"

This is a legitimate Windows path.

Now imagine passing it through multiple layers:

Node.js argument handling.
CMD.
PowerShell 5.1.
PowerShell 7.
An MCP client.
A process launcher.

Every layer can interpret certain characters differently.

During our tests, unescaped "&" broke VS Code commands. A path containing "%OS%" could also be interpreted as an environment-variable reference when passed through "cmd /c".

PowerShell introduced another layer of complexity because ".ps1", ".cmd", and ".exe" commands do not necessarily behave identically.

The result?

You cannot simply quote everything and assume the problem is solved.

We implemented explicit argument handling and escaping, then tested the actual values received by the target programs.

Our recorded Windows compatibility work includes a quoting probe with 45 successful checks across PowerShell 5.1, PowerShell 7.6.7, CMD, multiple executable types, and difficult project paths.

That's not glamorous software engineering.

But it is necessary software engineering.

⚙️ Problem No. 3: Passing CI Does Not Mean Your MCP Server Works

Here is another misconception.

A green CI badge does not automatically mean your MCP server works in a real desktop application.

There are several distinct stages:

The package installs.
The launcher starts the correct executable.
The server initializes.
The MCP client establishes a connection.
The client discovers the available tools.
An actual request reaches the server and returns the expected result.

A test that verifies only the first three stages does not prove the entire integration works.

We therefore added compatibility checks that go beyond simply running the test suite.

Our "doctor" command checks the Node.js environment, package configuration, project folders, starts the server independently, performs a real MCP handshake, and checks the available tools.

This does not prove that every desktop client's UI or agent works correctly. That distinction matters.

But it provides considerably stronger evidence than checking whether a configuration file exists.

🧪 Problem No. 4: Cross-Platform Tests Need Different Expectations

Windows and Linux do not implement every filesystem behavior identically.

For example, a Linux test using:

"chmod 000"

cannot simply be copied into a Windows test suite and expected to mean the same thing.

Windows uses a different permission model.

Our compatibility records explicitly identify a permission-related test as skipped on Windows rather than pretending that the same behavior was verified.

That is an important distinction.

Cross-platform testing is not about forcing every operating system to behave identically.

It is about testing equivalent guarantees using the mechanisms each platform actually supports.

🔬 What We Learned Building Sentinel-IR-MCP

This is not theoretical research.

We encountered these problems while developing our own MCP server and testing its compatibility.

The project has separate components:

"Sentinel-IR-MCP on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp) – the MCP server.
"sentinel-ir-mcp on npm" (https://www.npmjs.com/package/sentinel-ir-mcp) – the published Node.js package.
"sentinel-ir on npm" (https://www.npmjs.com/package/sentinel-ir) – the underlying code analysis engine.
"Sentinel-IR-MCP on Glama" (https://glama.ai/mcp/servers/jakcmencz/sentinel-ir-mcp) – the MCP directory listing.
"Sentinel-IR Playground" (https://sentinel-ir-playground-dc30c8.gitlab.io/) – the browser-based analysis playground.

The implementation includes platform-aware launch configuration, compatibility checks, Windows-specific argument handling, and a separate diagnostic command.

We also maintain a dedicated "Windows compatibility test record" (https://github.com/jakcmencz/sentinel-ir-mcp/blob/main/COMPATIBILITY.md), documenting what was actually tested and what remains unverified.

That last part is important.

We don't consider an untested environment supported just because the code looks portable.

💸 The Hidden Windows Tax

Every platform-specific failure has a cost.

A developer loses time reproducing it.

A maintainer needs another compatibility fix.

A CI pipeline needs another test.

A user encounters another installation problem.

And when the software is designed for AI agents, the consequences multiply.

An MCP server that cannot launch is not merely inconvenient.

The agent loses access to the functionality it was supposed to provide.

You can have a sophisticated analyzer, a carefully designed security model, and a fast execution engine.

But none of those capabilities matter if the process never starts.

🚀 The Next Bottleneck Is Not Intelligence

The AI industry is moving rapidly toward autonomous development environments, persistent agents, and increasingly sophisticated MCP integrations.

Yet developers still have to solve problems that have existed for decades:

Process execution.

Shell compatibility.

Filesystem semantics.

Environment variables.

Executable resolution.

Cross-platform packaging.

These are not exciting problems to advertise.

They are the problems that determine whether someone can actually use your software.

Part 1 was about removing unnecessary waiting from Windows CI/CD.

Part 2 is about removing unnecessary friction from Windows compatibility.

Because building an AI tool that works on your machine is not the same as building one that works for everyone.

And Windows developers deserve better than being an afterthought.

💨One more critical thing that people don't realize about slow CI/CD for AI agents:
Why the hell would you wait an hour and a half for a single merge with fixes when you can have everything—the bug fixed, tests run, and code merged—completely done in under 9 minutes?
While I was stuck waiting 90 minutes for one single merge on GitLab, we could have built and deployed 10 consecutive patches on this new GitHub setup.
When your infrastructure is slow, you aren't just losing time—you are paralyzing the agent's velocity. An AI agent doesn't need coffee breaks; it needs instant feedback loops to learn, adapt, and push the next iteration. Slow CI kills that rhythm. Fast CI unlocks pure exponential development.🤔😃

Independent Engineering Projects

Built as independent engineering experiments across AI, software analysis, security, and autonomous systems.

Evaluated by reproducible evidence, not by the number of layers.

Explore the projects:

Support the work: ⭐ Star the repositories on GitLab.

Connect: Follow me here on DEV Community or explore the Playground.

Each project is distributed under its own license. Check the corresponding repository or NPM package for licensing terms.

DEV Community: jackymenCZ (jackymenCZ)

Windows GUI check — published sentinel-ir-mcp 0.5.9. The No-Login Paradox 2

Verdict

Environment and configuration

Verified results

Visual evidence

Failure evidence and limitations

sentinel-ir 0.5.9 / sentinel-ir-mcp 0.5.9: ordinary-user test, round 3 (macOS)

Summary

Results of the 8 regression checks

Issues

1. bug: doctor --client vscode reports exclusions and audit log that contradict the real config

2. bug: the stale-npx-cache warning misses a pinned copy and names a range the user never wrote

3. bug (docs vs behaviour): an explicit unsupported language is not reported as unknown

4. docs: the library README field reference does not match the shape analyze() returns

5. docs: the library "Why send IR" table and the "about 400 characters" claim are out of date

6. papercut: doctor says [ok] analyze_directory works after checking 0 files

7. papercut: copy-paste hints leave out --client / --global

8. papercut: MCP analyze_code.language is case-sensitive while the library is not

9. papercut: mailto: / data: paths are treated as relative file names

10. papercut: the URL refusal is formatted differently from the other refusals

11. papercut: the folder summary in log leaves out the symlink and incomplete counts

12. papercut: inconsistent per-file entries in analyze_directory

13. papercut: Rust process::exit naming in broken and parsed files

14. papercut: examples/basic.js prints a stack trace for a missing file

15. papercut (cosmetic): text layout

16. docs: gaps in the MCP README

17. docs: npx range refresh depends on the npm version

18. docs: the library alias list is incomplete

What I verified works

sentinel-ir 0.5.9 / sentinel-ir-mcp 0.5.9: Windows user test (round 3)

Summary

Issues found

Issues in detail

1. bug: explicit unsupported language doesn't match the README (sentinel-ir)

2. papercut: MCP analyze_code language is case-sensitive, the library isn't

3. papercut: doctor says [ok] when 0 files were checked

4. papercut: the stale-npx-cache warning labels the copy differently on npm 10 and npm 11

5. docs: the README upgrade claim depends on the npm version

6. papercut: examples/basic.js prints a raw stack trace for a missing file

7. docs: the "Fewer tokens" table is stale (sentinel-ir README)

8. docs: gaps in the sentinel-ir-mcp README

9. papercut: Rust std::process false positives (documented behaviour)

10. papercut (transient): doctor update check

Unverified / blocked

The 8 regression checks for 0.5.9

0.5.8 fixes rechecked

Verified working

Sentinel-IR and Sentinel-IR MCP are open for sponsors (and yes, an AI writes most of the code)

The short version

What these two things are, in one paragraph each

The honest part

What it saves you (measured, not vibes)

Why monthly, not one-off

Where the money goes

Where we are today

Can't sponsor? Still helps

Sentinel-IR MCP 0.5: give your AI agent a library card, not the master key

TL;DR

The problem: agents read like a vacuum cleaner

Triage first, read later

The security model, in plain terms

What's new in 0.5

Rust (0.5.0)

Updates that actually arrive (0.5.1)

Tool descriptions agents can actually use (0.5.2–0.5.3)

doctor, the part we tried hardest to break (0.5.4–0.5.5)

The audit release (0.5.6)

Supply chain and release hygiene

Getting started

Where it fits in a company

The honest limits

What's next

Sentinel-IR 0.5: your LLM doesn't need the whole file, it needs the gossip

TL;DR for people who scroll

Why bother: the "senior dev at standup" problem

What the output looks like

New in 0.5: Rust

New in 0.5: the code that runs before your code runs

New in 0.5: harder to fool, harder to stall

1. bug: `doctor --client vscode` reports exclusions and audit log that contradict the real config

3. bug (docs vs behaviour): an explicit unsupported `language` is not reported as `unknown`

4. docs: the library README field reference does not match the shape `analyze()` returns

6. papercut: `doctor` says `[ok] analyze_directory works` after checking 0 files

7. papercut: copy-paste hints leave out `--client` / `--global`

8. papercut: MCP `analyze_code.language` is case-sensitive while the library is not

9. papercut: `mailto:` / `data:` paths are treated as relative file names

11. papercut: the folder summary in `log` leaves out the symlink and incomplete counts

12. papercut: inconsistent per-file entries in `analyze_directory`

13. papercut: Rust `process::exit` naming in broken and parsed files

14. papercut: `examples/basic.js` prints a stack trace for a missing file

1. bug: explicit unsupported `language` doesn't match the README (sentinel-ir)

2. papercut: MCP `analyze_code` `language` is case-sensitive, the library isn't

3. papercut: `doctor` says `[ok]` when 0 files were checked

6. papercut: `examples/basic.js` prints a raw stack trace for a missing file

9. papercut: Rust `std::process` false positives (documented behaviour)

10. papercut (transient): `doctor` update check

`doctor`, the part we tried hardest to break (0.5.4–0.5.5)