Skip to content

fix(daemon): print the validation detail when the secure endpoint cannot be created - #1446

Closed
mlandolfi90 wants to merge 1 commit into
DeusData:mainfrom
mlandolfi90:fix/endpoint-validation-detail
Closed

fix(daemon): print the validation detail when the secure endpoint cannot be created#1446
mlandolfi90 wants to merge 1 commit into
DeusData:mainfrom
mlandolfi90:fix/endpoint-validation-detail

Conversation

@mlandolfi90

@mlandolfi90 mlandolfi90 commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

The MCP-client startup path swallows the reason for a refused endpoint:

cbm_daemon_ipc_endpoint_t *endpoint = cbm_daemon_bootstrap_endpoint_new(NULL);
if (!endpoint) {
    (void)fprintf(stderr, "codebase-memory-mcp: secure daemon endpoint could not be created\n");
    return EXIT_FAILURE;
}

Every refusal inside the ancestor DACL walk — owner mismatch, an untrusted grant, a failed repair — arrives as that one sentence. cbm_daemon_ipc_validation_detail() has already recorded exactly which component failed and why, and the worker path a few hundred lines up already prints it for the identity check. This just does the same at the endpoint site.

Concretely, this turns

codebase-memory-mcp: secure daemon endpoint could not be created

into

codebase-memory-mcp: secure daemon endpoint could not be created - C:\Users\<user>\AppData: DACL entry 0 grants mutation rights 0x000d0152 to untrusted identity (other S-1-15-3-...)

Diagnosing the first form took a purpose-built instrumented binary. The second names the directory, the mask and the SID.

No behaviour change beyond the message; the detail buffer is a static already populated on this path.

🤖 Generated with Claude Code

@mlandolfi90 @claude
fix(daemon): print the validation detail when the secure endpoint can…
4ff59cb 
…not be created

The MCP-client path swallowed the reason: any refusal inside the
ancestor DACL walk surfaced as a bare 'secure daemon endpoint could not
be created', undiagnosable in the field. The worker path already prints
cbm_daemon_ipc_validation_detail(); do the same here.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: mlandolfi90 <mlandolfi90@users.noreply.github.com>
@mlandolfi90
mlandolfi90 requested a review from DeusData as a code owner August 4, 2026 19:09
@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

  • It will not be closed for inactivity. No stale bot touches pull requests here.
  • It may still sit a while before a human reads it. That is on us, not on you.
  • Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

  • Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
  • Get CI green, or say which failures you believe are pre-existing.
  • Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
  • Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

@mlandolfi90

mlandolfi90 commented Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

CI note: the only red is security / codeql-gate, which timed out with the analysis still queued after 90 polls (BLOCKED: CodeQL timeout) — no alerts were raised, it was never scheduled. I opened five PRs in quick succession, so this may be queue pressure I caused; apologies if so. Everything else is green.

🤖 Generated with Claude Code

@DeusData

DeusData commented Aug 15, 2026

Copy link
Copy Markdown
Owner

Thank you for this, and sorry for the long silence.

This one is now superseded — the validation detail is printed on main today. src/main.c:2774 calls cbm_daemon_ipc_validation_detail() on the daemon-side failure, and the CLI-side twin landed last night (4cbecb6, #1627) so the secure CLI coordination could not be created (endpoint) path names the directory and the rule that refused it too. Both ship in v0.10.5.

Your diagnosis was right, and it was the right fix to ask for: four separate reporters hit that bare message, and one of them ended up building an instrumented binary just to discover a single ACE was the cause. That should never have been necessary, and this is exactly the change that stops it.

Nothing here reflects on the patch — it sat unreviewed while the same problem got fixed from another direction, which is our failure of process rather than anything about your work. Your #1447 fared better: it shipped, with you named as co-author. See my comment there.

@DeusData DeusData mentioned this pull request Aug 15, 2026
Closed
@DeusData

DeusData commented Aug 15, 2026

Copy link
Copy Markdown
Owner

Closing as superseded — src/main.c:2774 prints cbm_daemon_ipc_validation_detail() on main today, and the CLI-side twin landed in #1627. Both ship in v0.10.5. Your diagnosis was right, and reporters had been building instrumented binaries to get this information; thank you for pushing on it.

@DeusData DeusData closed this Aug 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@DeusData DeusData Awaiting requested review from DeusData DeusData is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@mlandolfi90 @DeusData