Thanks for support..
Release: "Sentinel-IR-MCP v0.2.2 on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp/-/tree/v0.2.2?ref_type=tags)
P...
For further actions, you may consider blocking this person and/or reporting abuse
Which client was the one that still failed on Windows: a desktop app or a CLI? Asking from the Auten team (we ship a computer-use MCP for Mac, Windows and Linux), and the Windows trap we'd add to your matrix is spawning rather than quoting: Claude Code's docs say local servers started with
npxon native Windows need thecmd /cwrapper, sincenpxis reallynpx.cmd. Writing the client's JSON config with anargsarray instead of one command string also sidesteps most of the quoting cases.Thanks, that's a useful distinction. Looking back at the Windows results, I should clarify my wording: I haven't confirmed an end-to-end failure in a Windows desktop client in this rerun.
The confirmed failure was at the process-launch level:
So your point about spawning versus quoting is exactly relevant. Quoting a path correctly doesn't help if the executable can't be launched in the first place.
I also tested the native Claude Code CLI 2.1.308 on Windows Server 2022. In PowerShell 5.1, I added the server for a path containing spaces, an apostrophe, "$", "&", "%", "^", and parentheses. "claude mcp get" reported Connected, and I verified that the stored path matched the original exactly. That was one specific CLI/shell/path combination, not a full end-to-end matrix.
The 45/45 quoting checks passed across PowerShell 5.1, PowerShell 7, and "cmd.exe", but the actual Windows desktop GUI clients weren't retested on this commit. The config and "doctor" checks shouldn't be mistaken for proof that those apps themselves loaded the server.
Your suggestion gives me a useful next step: test executable resolution, process spawning, argument preservation, client connection, and an actual tool call as separate stages. I'll also make sure the Windows "cmd /c" case is explicit in the compatibility matrix.
Thanks for pointing this out. It's exactly the kind of distinction I want the tests to expose.☺️
That staged split is the right call. One cheap check for the version stage: have the server put its real package version in serverInfo in the initialize response, and have the test assert it. Then "npx resolved 0.2.2 while I was testing 0.2.3" fails loudly at the handshake instead of hiding inside a passing tool call.
That's a really good catch 😄 I like this idea because it would make the version mismatch obvious right away instead of letting a test pass while running the wrong package.
I'll fix this before the v0.2.3 release on November 6. It's a small detail, but exactly the kind of detail that can make testing much more trustworthy.
Thanks for spotting it🙂
I'd prioritize one complete client workflow first, chosen from the users you can actually test with, while keeping a small smoke test on the other OS. The strongest milestone would be the exact published package installed into a real client, followed by one analysis call against a known fixture with an expected result.
For trust, I'd want a preview of the config change, preservation of unrelated servers, an explicit executable/args list, and a reversible uninstall. Then distinguish configuration written, server connected, tools listed and analysis call verified in the report. Your 0.2.3 versus published 0.2.2 distinction is especially useful here.
What is the first client/OS pair you can recruit a few real users for? That would guide the next end-to-end test more than a broad platform vote.
That's a good way to narrow the scope. I agree that the next milestone should be a real end-to-end workflow, not just a successful setup or MCP handshake.
My most actionable first candidate is Windows + Claude Code CLI. In my latest test, native Claude Code 2.1.308 accepted the server configuration for a project path containing spaces and special characters. "claude mcp get" reported "Connected", and I verified that the stored path matched the original exactly. However, I haven't verified an actual analysis tool call in Claude Code yet.
There's an important version distinction, too. My 0.2.3 code was under local test, but the generated "npx -y sentinel-ir-mcp@0.2" command resolved to the published 0.2.2 package. So I need to make the next test explicitly version-pinned rather than treating the local setup code and the published server as one version.
I'd use a small fixture with a known expected result and separate checks for:
I should be transparent about one limitation: I don't yet have a recruited group of real users, so Windows + Claude Code is the first candidate based on my current test coverage, not evidence that this is where the most users are.
Would you be interested in helping identify a few people who could test that exact workflow? I'd rather validate one complete path with real users than claim broad compatibility based on a large matrix of partial checks.☺️
Yes, happy to help shape a focused tester call. I don't have confirmed Windows testers to offer yet, so I'd start with an open invitation here for 2–3 people already using native Windows + Claude Code CLI.
Could you share one public issue containing the exact published version to pin, the fixture and expected result, and the commands for setup and cleanup? Your distinction between local 0.2.3 and published 0.2.2 is important; each report should record the package actually launched, alongside Windows, Node, and Claude Code versions.
I'd also include a deliberately invalid fixture with an expected error, so we can distinguish a useful analysis result from a tool call that merely returned successfully. A sanitized transcript covering tools/list, the analysis call, the expected-result check, and cleanup would make the outcome independently reviewable.
That gives volunteers a bounded task and a clear place to report where it breaks. Windows + Claude Code can then stay labeled as the first validation target until those runs provide stronger evidence.
Thanks, man ☺️
Just to give you a bit of context, v0.2.3 isn't planned for release until November 6, 2026. I'm still checking a few small details before publishing it. I'm an AI agent architecture enthusiast, not someone who's been building complex software systems for years, so I'm learning a lot along the way. 😀
But that's exactly why I appreciate suggestions like yours. The idea of testing the exact published package, checking both valid and invalid input, and letting someone else reproduce the whole thing makes a lot of sense to me.
I'm already preparing for that kind of testing, so your suggestion fits right into what I want to do next. I don't want to claim something works just because it worked on my own setup.
Thanks for helping me think this through. It's much easier to build something useful when people share ideas like this. 🙂
Thanks for clarifying the November 6 target 🙂 Until the package is published, I’d label any tester result “pre-release, commit ”; afterward, record the exact published version separately. That keeps useful early feedback without mixing it with release compatibility evidence.
For the tester invitation, a short result template could be: Windows version / Claude Code version / exact server version or commit / fixture used / expected versus actual result / cleanup result. Please use a disposable project with synthetic files, and redact private paths or credentials from logs. One complete report—including a failure—is more useful than a broad “works on Windows” claim. No need to rush the release for the test.
Thanks, man 😀 This is really helpful.
I especially like the distinction between pre-release testing and testing the actual published package. I don't want to mix those up or claim more than the evidence shows.
The November 6 release date stays as planned. Before that, I still have a few details to check, and your checklist gives me a much clearer idea of how to prepare the testing.
I'll also keep the test environment disposable and make sure the results can be shared without exposing private paths or credentials.
And I agree about reporting failures too. If something breaks, that's useful information, not something to hide.☺️
Thanks for helping me make this more reliable, one step at a time. 🙂
test it where your users actually install first, port the checks after.
That's a great point 😄 No point trying to test everything everywhere before knowing where people actually use it.
I'll keep this in mind for the next round of testing. First, I'll focus on getting one real installation and the full workflow right, then expand the checks to other platforms.
Still learning as I go, so I really appreciate perspectives like this. Thanks ☺️