ryanmcdonough moves to plug a chat-creation loophole

A logged-in user could start chats attached to projects they had no business touching - ryanmcdonough proposed slamming that door shut.

securitychat-ui

The problem was quiet but real. When someone created a new chat, the system took the project it was attached to on trust, without checking whether that user actually had any right to that project. In practice, any signed-in user could spin up chats inside other people's projects.

ryanmcdonough's fix makes the system confirm entitlement before writing anything: if you don't own or share access to the named project, the request is turned away as if the project simply doesn't exist - so the response never even reveals whether a given project is real. Owners and shared members see no change. It's a tight, single-purpose patch that reuses the existing access-check plumbing rather than bolting on new machinery. Worth noting: the proposal was closed without being merged, so this guard never actually landed.

So what Anyone evaluating this codebase for real client matters should care that this access hole was flagged - and that the proposed fix, for now, sits unmerged.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from ryanmcdonough/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
69c283ee Enhance chat creation endpoint to check project access using user email ryanmcdonough 2026-04-30 ↗ GitHub

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-816.md from inside the repo you want the changes in.

⬇ Download capture-thread-816.md