Reported issues for Baron
Pod holds 17 of 23 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to Baron.
Most discussed
issue.block and issue.unblock are missing from the recipe engine
Omission in #14. Every other issues primitive is exposed as a recipe op in RECIPE_OPS (recipe.ts:8-22) and dispatched in engine.ts — create, get, update, transition, reconcile, comment, assign, link, query, whoami, iterations, setIteration. The two primitives #14 added are not, so a recipe cannot set or clear the blocked flag at all. That matters more than it sounds: recipes are where workflow opinion is supposed to live (invariant #3), and decision #19 says the engine enforces the rules rather
Read the thread · 2026-08-13 · closed · 4 comments
Register on the surfaces where MCP servers are discovered
Baron is currently listed in none of them. Every one is free and one-off, and their effect compounds — Context7 reached ~974k weekly npm downloads through this route with no Hacker News traction at all.
- Official MCP Registry (
server.json+ namespace verification) - Glama
- mcp.so
- PulseMCP
- Docker MCP Catalog (via PR)
-
awesome-mcp-servers -
awesome-claude-code - Claude Code community marketplace submission
Note that roughly half of published MCP serve
Read the thread · 2026-08-10 · open · 3 comments
The stale-companion check only speaks in one direction, and the other one is routine
companionNotice reports a plugin OLDER than the server and stays silent when it is newer. I reasoned that a newer client means someone pinned the server back deliberately. Shipping 0.36.0 showed that reasoning is wrong: the skills ship through the marketplace and the recipes they call ship through npm, so a plugin newer than its server is not a deliberate act, it is the ordinary state between two updates. And it is not harmless — 0.36.0's task-sync skill calls the task-sync-report recipe, which
Read the thread · 2026-08-21 · closed · 2 comments
The plugin freezes the skills at a commit but rolls the server to @latest
plugin.json pins nothing about the skills — Claude Code installs them at a git SHA and they stay there — while the same manifest launches the MCP server with npx -y @lonca/baron-mcp-server@latest, which moves on every restart. The two drift apart silently and the drift is not cosmetic. A real install (BeeMaster, plugin frozen at 2026-07-15) was measured against the 0.34.0 server it actually launches: its skills reference 21 baron_* tool names and 17 of them no longer exist, because the 36-to-14
Read the thread · 2026-08-20 · closed · 2 comments
The documented mcp-publisher download overwrites Baron LICENSE and README
RELEASING section 3 says: curl -L .../mcp-publisher_windows_amd64.tar.gz | tar xz — run from the repository root, as the surrounding steps are. That tarball contains three members: LICENSE, README.md and mcp-publisher.exe. Extracting it into the root replaces Baron's Apache LICENSE with the MCP registry's transitional MIT/Apache notice and Baron's README with the registry's, in the working tree, silently. The step is documented immediately before a release, which is exactly when someone runs git
Read the thread · 2026-08-20 · closed · 2 comments
Ship a Linear issues adapter — the first provider whose states are scoped
Phase 4 of the #16 plan, reordered ahead of the baron init work because the adapter is what proves the scoped contract against reality; designing init's proposal flow against a memory fake first would only mean reshaping it once the introspector exists. Scope: a new packages/adapters/linear with a CapabilityManifest, a GraphQL IssuesTransport, and registration in packages/providers. Facts already established from the live schema so the manifest is not guesswork: hierarchy is native (Issue.parent
Read the thread · 2026-08-17 · closed · 2 comments
Pre-consolidation tool names and counts survive across the docs the README sends newcomers to
Fallout from #6 that the consolidation change did not sweep. docs/mcp.md's toolsets section still quotes the pre-consolidation counts (27 -> 11) on a page that elsewhere states the current numbers, so it contradicts itself. Both hands-on walkthroughs list pre-consolidation tool names in their 'did it install correctly' check, so the very step meant to confirm a working install names tools the server never publishes. The Azure DevOps walkthrough README uses six names that no longer exist. ROADMAP
Read the thread · 2026-08-14 · closed · 2 comments
mcp-handshake cannot launch npx on Windows, so the one path it exists to verify goes untested there
Repro on Windows: node scripts/mcp-handshake.mjs npx -y @lonca/baron-mcp-server@latest. Observed: 'handshake FAILED: could not launch: spawn npx ENOENT'. Expected: the same initialize + tools/list exchange it performs against the container. Cause: npx on Windows is npx.cmd, and child_process.spawn without a shell will not resolve an extensionless shim. It matters because npx is the launch path RELEASING.md tells you to smoke-test after every publish, and this is the maintainer's own platform — t
Read the thread · 2026-08-14 · closed · 2 comments
Most recent
README describes the token-pasting setup that is no longer the first thing init offers
Repro: read the Quick start. Step 1 says init 'prompts for the token (hidden)'. Observed since #68 and #70: an interactive init offers GitHub's device flow first and opens the approval page, and pasting a token is the fallback for someone who wants the narrower fine-grained credential. The README therefore describes the worse of the two paths as though it were the only one, on the page a new user reads first — and it says so at exactly the moment the registry listing starts sending new users. Al
Read the thread · 2026-08-14 · closed · 2 comments
Claim the Glama listing: ship glama.json and run the claim flow
Glama already produces a baseline entry from the official registry alone, so Baron will appear there without us; what the claim buys is control (display metadata, category, build spec) and, together with the Dockerfile from #75, staying off the AI-inferred-build path whose failure withholds distribution from search and category listings. Because loncadev is an organisation rather than a personal account, signing in with GitHub is not by itself enough to claim: the repo root needs glama.json with
Read the thread · 2026-08-14 · closed · 2 comments
Ship a Dockerfile so the server can be built and introspected in a sandbox
Highest-leverage artifact left in #10. Glama builds every open-source server in a sandbox and, when an AI-inferred Dockerfile fails to produce a working build, withholds distribution: the profile page survives but the server stops appearing in search, category listings and recommendations. Checking in our own Dockerfile takes us off the inference path entirely. The same file is the prerequisite for the Docker MCP Catalog, and Glama gates the punkpeye/awesome-mcp-servers submission, so three surf
Read the thread · 2026-08-14 · closed · 2 comments
Document that the MCP Registry org namespace needs a read:org token, which the device flow does not issue
Cost three rounds of browser sign-in during #10 before the cause was found in the registry source. The registry grants io.github.
Read the thread · 2026-08-14 · closed · 2 comments
Published npm package carries no mcpName, so the MCP Registry refuses to list Baron
Blocks #10. The official registry will not accept a server whose npm package cannot be proven to belong to the same publisher, and for npm the proof is an mcpName field in the PUBLISHED package.json matching server.json's name (io.github.loncadev/baron). Repro: npm view @lonca/baron-mcp-server@0.32.0 mcpName -> empty; mcp-publisher publish then fails validation for the package. Expected: the field ships. Fix: add mcpName to packages/mcp-server/package.json (prep-publish mutates and rewrites the
Read the thread · 2026-08-14 · closed · 1 comment
server.json still says 0.31.1 after v0.32.0 shipped
Caught while preparing the MCP Registry submission (#10). server.json carries the version twice — once at the top level and once inside the npm package entry — and both still read 0.31.1 after v0.32.0 was published. RELEASING.md bumps the ten package.json files and says nothing about this file, so it drifts every single release. It matters more than a stale string: server.json is exactly what the official MCP Registry ingests, so submitting it now would advertise a version that is not the latest
Read the thread · 2026-08-14 · closed · 2 comments
Toolsets were never built, so #7 shipped half of what it claimed
Issue #7 was "Add toolsets, default to ~7 tools, and never publish unbound ports" and it is closed. Only the second half exists. Grepping the whole mcp-server package for toolset / TOOLSET / BARON_TOOLS returns nothing outside tests: there is no default set, no opt-in, no env or policy switch. activeToolDefinitions filters by BOUND PORT and nothing else. Measured against the real definitions: an issues+scm install — this repository shape, and the common one — publishes 27 tools; all ports bound
Read the thread · 2026-08-14 · closed · 2 comments
ROADMAP describes as pending three things that have shipped
ROADMAP.md is the file that states where Baron is going, and it now tells a reader things that are not true. Gate 1 lists putting Baron on Baron as outstanding; #18 closed once two changes went through task-start -> task-finish -> task-land end to end. Gate 2 says "Today Baron publishes 34 MCP tools" — it is 36 since #14 added baron_issue_block and baron_issue_unblock, so the number a reader checks against is wrong and the argument (Cursor caps a session at 40) is understated. Gate 3 lists four
Read the thread · 2026-08-14 · closed · 2 comments
The checks warning added in #28 is discarded on the MCP path and misleading on Azure
Two defects in the guard landed by #28, found by auditing it. FIRST, the warning reaches nobody where it matters. A message step is routed through options.asker.note (engine.ts:519), and the non-interactive asker the recipe SERVICE uses has note() {} — an empty function (service.ts:47). RunRecipeResult carries only context (engine.ts:58-61) and service.run returns result.context (service.ts:104), so there is no channel the text could return through even if it were recorded. On `baron_recip
Read the thread · 2026-08-13 · closed · 2 comments
The remaining reports are on the project's issue tracker.