Reported issues for RoselineMCP
Pod holds 23 of 37 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 RoselineMCP.
Most discussed
[Bug]: The failure envelope names no checkout, so an omitted project miss stays undiagnosable
Scope sharpened 2026-08-20 by a backlog triage pass. Two thirds of this issue have landed; the old title and implementation plan described work that is already merged, so a worker picking it up cold would have re-implemented #143. What remains is one specific gap, named below. The original report is preserved at the bottom.
What is left
The failure path names no checkout. #143 added resolvedPath to every response from a tool with
an optional project — but only on the **s
Read the thread · 2026-08-19 · closed · 4 comments
[Bug]: The write confirmation asks a human before establishing there is a non-empty write to approve
Rescoped 2026-08-20 by a backlog triage pass. This issue was filed against one instance (
newSourcevalidated after the prompt). That instance is fixed — verified againstdev@eb19739, not inferred from a PR title. The root it was an instance of is still open, and one further instance of it remains. The issue now tracks the root; the original report is preserved verbatim at the bottom.
What happened?
**The root: the write-confirmation gate asks a human before estab
Read the thread · 2026-08-20 · closed · 3 comments
[Bug]: The write confirmation is composed per tool by raw interpolation, so caller input can forge the sentence a human approves
What happened?
Found by the code-review pass on PR #157 (issue #154). Pre-existing — not introduced by that PR, though #157's longer sentence makes the first half of it easier to exploit.
ToolExecutionHelper.ResolveWriteModeAsync (#129) centralised the write-confirmation gate's
policy — when to elicit, how to read the answer, what a timeout means — but deliberately left the
wording to each tool. Each of the three write tools therefore builds its sentence itself, by
interpolati
Read the thread · 2026-08-20 · closed · 2 comments
[Bug]: resolvedPath can name a .sln that does not contain the project that answered
What happened?
resolvedPath — the field added in #143 so a caller can tell which checkout and which project file
actually answered — can name a .sln that does not contain the project the symbols came from.
ProjectLoader.LoadAsync resolves a .csproj target by first looking for the nearest ancestor
.sln and opening it, then locating the target inside it:
var solutionPath = FindSolutionFile(targetPath);
if (solutionPath != null)
{
var solution = await workspace.Ope
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/151) · 2026-08-20 · closed · 2 comments
### [Feature]: Extract the duplicated write-confirmation block shared by the three write tools
Continues #125.
## What problem does this solve?
The write-confirmation block is copy-pasted verbatim across all three write tools. `ApplyFixesTool.cs`,
`EditMemberTool.cs` and `RenameSymbolTool.cs` each carry the same ~12 lines:
```csharp
var effectivePreviewOnly = previewOnly;
string? declineNote = null;
// Use the caller's request token (not the wall-clock timeout) for the human confirmation
// round-trip: think-time must not be charged against the analysis budget.
if (!previewOnly && !awa
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/129) · 2026-08-19 · closed · 2 comments
### [Feature]: Surface key examples for diagnostics no code fix provider can repair (suggest_fix_examples)
## What problem does this solve?
`apply_fixes` can only repair a diagnostic for which a Roslyn or Roslynator `CodeFixProvider`
exists. `CodeFixProviderFactory.LoadProviders()` builds an ID → provider-type map by reflecting
over the Roslyn built-ins plus the bundled `AnalyzerCatalog` assemblies;
`DiagnosticFilterService.IsFixableDiagnostic()` reads that map, and it is exactly what populates
`list_diagnostics`' `suggestedFixableIds`. Anything outside that map is **reported and then
abandoned**: t
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/180) · 2026-08-21 · open · 1 comment
### [Bug]: Option-binding tests still fail when a ROSELINE_ variable is exported with different casing
Continues #132.
**Related:** #126, #128, #131, #140
## What happened?
#132 made `RoselineMcpOptionsBindingTests`' two `*_Binds_From_The_Documented_Environment_Variable`
tests independent of an ambient `ROSELINE_` export by wrapping each in a scope that clears the
variable for the duration:
```csharp
const string key = "ROSELINE_RoselineMCP__ConfirmDestructiveWrites";
using var _ = ScopedEnvironmentVariable.Set(key, null);
That clears one exact key spelling. But the two sides of this
Read the thread · 2026-08-20 · closed · 1 comment
[Feature]: Verify edits against the compiler before writing, and add check_compilation
What problem does this solve?
RoselineMCP's value proposition today is token efficiency: a measured 89% median reduction per
tool call, and ~13% end-to-end in realistic, self-directed agent use
(docs/AGENT-BENCHMARK.md, n=1).
That proposition has a shrinking moat — context windows grow, caching gets cheaper, and a 13% saving becomes invisible. More tellingly, the end-to-end benchmark records that "quality was identical in every cell": **Ros
Read the thread · 2026-08-19 · closed · 1 comment
Most recent
[Bug]: ProjectLoader's explicit-.csproj ambiguity fallback catches ArgumentException too broadly
Related: #213, #218
What happened?
ProjectLoader.FindSolutionFile's ambiguous-solution-walk fallback (added by #213 / PR #218) is
gated with:
catch (ArgumentException) when (IsExplicitCsprojPath(project))
{
// degrade to a standalone load of the named .csproj
}
This catches the exception type, not a signal specific to "the ancestor walk found more than one
.sln". Anything else in FindSolutionFile's call chain that happens to throw ArgumentException
(e.g.
Read the thread · 2026-08-26 · closed · 0 comments
[Bug]: FindSolutionFile's ambiguity refusal (#172) breaks an explicitly-named .csproj in a multi-solution monorepo
What happened?
ProjectLoader.FindSolutionFile (the ancestor .sln walk LoadAsync uses once a .csproj target
is resolved) gained an ambiguity check in #172/PR #192: when an ancestor directory holds more than
one candidate .sln, it now throws ArgumentException instead of silently taking slnFiles[0].
That's correct for the AppleDouble-shadow scenario #172 fixed, but the check runs unconditionally —
for every non-.sln target LoadAsync resolves, including one the caller named
Read the thread · 2026-08-26 · closed · 0 comments
[Feature]: Pin website/src/data/tools.ts to the reflected [McpServerTool] set — #197's root cause survives
What problem does this solve?
Continues #197.
#206 made the website's tool count self-consistent. It did not make it correct, and the distinction is the whole of this issue.
The headings now derive from website/src/data/tools.ts, so the page can no longer contradict its own
grid. But tools.ts is itself a hand-maintained array, and nothing links it to the server's actual
[McpServerTool] set. The chain has two links and #206 closed only the second:
C# [McpServerTool]
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/208) · 2026-08-25 · closed · 0 comments
### [Feature]: ElicitationTests' prompt-assertion helpers encode stale assumptions about the prompt frame
## What problem does this solve?
Deferred by PR #202 (which closed #173) — two defects in `RoselineMCP.Tests/Protocol/ElicitationTests.cs`
that share one root: the **prompt-assertion helpers reason about the sentence heuristically** — by
counting apostrophes and hunting for quote characters — rather than from the `WriteScope` vocabulary
the sentences are actually rendered from. Because the helpers encode assumptions about the *frame*,
they drift whenever the frame changes, and #173 changed it.
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/204) · 2026-08-25 · closed · 0 comments
### [Bug]: The apply_fixes confirmation for a .csproj target reads like a promise to rewrite that file
## What happened?
Deferred deliberately by PR #202 (which closed #173) — filed so the decision is tracked rather than
left in a source comment.
#173 re-ordered two of the three write-confirmation sentences so the resolved target is the **last**
thing in every prompt. That closed a real hole, but it changed the frame the `apply_fixes` sentence
sits in, and the `.csproj` branch inherited a new ambiguity from the move.
`WritePrompt.RenderPrimaryProjectOf` (`RoselineMCP/Models/WriteScope.cs`) bra
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/203) · 2026-08-25 · closed · 0 comments
### [Bug]: verification/check_compilation error paths still anchor to Solution.FilePath — the fourth site diverging from resolvedPath
## What happened?
`Continues #181.`
#151 changed how `resolvedPath` is computed. #181 then updated the three consumers that had been
re-deriving the same anchor independently (`CodeNavigationService.BaseDirOf`, `CodeFixService`'s
`ApplyFixes`, `CodeEditService.RelativePath`) to read one authoritative value,
`LoadedProject.BaseDirectory`. Its scope named exactly those three.
**A fourth site was left behind, deliberately and with the reason recorded** — but it is still a
live divergence in ship
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/199) · 2026-08-25 · closed · 0 comments
### [Feature]: analyzerLoad — count references without analyzers instead of naming each, and name code fixers that fail to load
Continues #183.
**Related:** #180, #183, #188
## What problem does this solve?
#188 shipped the `analyzerLoad` block on `list_diagnostics`, `analyze_solution` and `apply_fixes`:
every analyzer reference that contributed nothing is named, with Roslyn's reason. Two edges were
left for the owner to decide, both measured while landing it:
**(a) Volume.** On a project that references the Roslynator packages — this repository, and any
target that does — **33 of 44** analyzer references yield no C#
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/191) · 2026-08-24 · open · 0 comments
### [Bug]: An analyzer reference that loads nothing is reported as nothing, and its code fixers are never loaded
## What happened?
Two things, one root shape: **RoselineMCP never tells the caller what it could not load.**
**(1) An analyzer reference that fails to load contributes zero diagnostics, silently.**
`DiagnosticComputationService.CollectAnalyzers()` calls `reference.GetAnalyzers(LanguageNames.CSharp)`
inside a `try/catch`. That catch only fires on an **exception**. Roslyn's `AnalyzerFileReference`
does not throw when it cannot load an analyzer type — it raises the `AnalyzerLoadFailed` event and
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/183) · 2026-08-21 · closed · 0 comments
### [Feature]: Add the two missing MCP tool-description components — Limitations and Examples — compactly
## What problem does this solve?
RoselineMCP's own end-to-end benchmark names the bottleneck: **"The highest-leverage improvement is
adoption."** (`docs/AGENT-BENCHMARK.md`, § Takeaways) In the greenfield and
brownfield cells the server was installed *and* the system prompt nudged the agent toward it, and it
made **zero** RoselineMCP calls — the tools were exercised only after `Read`/`Grep`/`Glob` were
removed. The same document's follow-up shows what moves that needle: server-level `instructio
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/179) · 2026-08-21 · closed · 0 comments
### [Feature]: Make turns and tool calls a first-class metric of the agent benchmark, alongside tokens and cost
## What problem does this solve?
This repo measures agent cost in three places, and **none of them counts turns.**
| Benchmark | Question it answers | Unit |
|---|---|---|
| `RoselineMCP.Benchmarks` (`BENCHMARKS.md`) | how long does a service call take? | milliseconds |
| `RoselineMCP.TokenBenchmark` | how compact is *one* tool response? | tokens per task |
| `docs/AGENT-BENCHMARK.md` | does an agent doing a real task end to end spend fewer tokens? | tokens / dollars per session |
Turns — the
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/178) · 2026-08-21 · open · 0 comments
### [Bug]: ApplyFixes' write loop can rewrite a file whose diff turned out blank
## What happened?
Found during code review of #162 (PR #174, which made `ApplyFixesResponse.ChangedFiles` reliably
diff-filtered — a document is only added once its unified diff turns out non-blank).
`CodeFixService.ApplyFixesAsync`'s "Apply changes if not preview only" block still writes from the
**raw Roslyn `changedDocuments` set**, not from the now-filtered `response.ChangedFiles`:
```csharp
// Apply changes if not preview only
if (!previewOnly && changedDocuments.Any())
{
foreach (va
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/175) · 2026-08-20 · closed · 0 comments
### [Bug]: A checkout path containing an apostrophe unbalances two of the three write-confirmation prompts
## What happened?
Found by the code-review pass on PR #170 (issue #161). **Pre-existing — not introduced by that PR**,
and deliberately left open by it: #161's own exposure table lists the target as injectable "only via a
checkout path containing `'`", which is the operator's filesystem rather than the caller's input.
#161 closed the caller-controlled half. `symbol` and `newName` now pass a whitelist inside
`WritePrompt.Render`, so a caller cannot open or close a quoted run. The **resolved tar
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/173) · 2026-08-20 · closed · 0 comments
### [Bug]: Shared IncidentalScan exposes macOS AppleDouble ghost files (._App.sln) to auto-discovery
## What happened?
`AttributesToSkip = 0` on the shared `IncidentalScan` options (introduced in #158,
`RoselineMCP/Services/ProjectLoader.cs`) is required so that dot-prefixed **directories** — the
`.claude/worktrees/<name>/` layout Claude Code creates — stay discoverable: the default
(`Hidden | System`) would hide them on Unix, since .NET infers `Hidden` from a leading dot.
The same options object is now used for `DiscoveryLevels`, `FindFilesAcross`, and
`FindSolutionFile` — three call sites t
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/172) · 2026-08-20 · closed · 0 comments
### [Feature]: Report the compile verdict after every file write via a `roseline-mcp guard` hook, not only RoselineMCP's own writes
## What problem does this solve?
The compile gate shipped in #133 is the first thing RoselineMCP does that a bigger context window
cannot make obsolete: it is a *correctness* guarantee, not a cost saving. But it only fires on
writes that go **through RoselineMCP's own write tools** — `edit_member`, `rename_symbol`,
`apply_fixes`. That makes it opt-in twice over: the agent must first choose RoselineMCP at all, and
then choose a RoselineMCP write tool over `Edit`/`Write`.
`docs/AGENT-BENCHMARK.m
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/168) · 2026-08-20 · closed · 0 comments
### [Feature]: Run the pre-registered end-to-end quality A/B for the compile-verified edit loop
Continues #133.
## What problem does this solve?
`docs/AGENT-BENCHMARK.md` currently ships a **pre-registered protocol with a deliberately empty
results table**. Its own header says so:
> **Status: not yet run.** The protocol is pre-registered here; the results table is deliberately
> empty. Do not cite anything from this section as a measurement.
That section exists because of the single most important line in the rest of that document:
**"Quality was identical in every cell."** Every bench
[Read the thread](https://github.com/Atypical-Consulting/RoselineMCP/issues/166) · 2026-08-20 · open · 0 comments
The remaining reports are on [the project's issue tracker](https://github.com/Atypical-Consulting/RoselineMCP/issues).