ask_codebase can return 404 research session links when blocking chats are created unauthenticated

[brianphillips]

Summary

ask_codebase can return a "View full research session" URL that 404s, even though the Chat row exists.

This appears to happen when /api/chat/blocking runs without an authenticated user (for example, missing/invalid SOURCEBOT_API_KEY in MCP while anonymous access is enabled).

Impact

• MCP users receive a chat URL that cannot be opened in the web UI.
• Persisted chat records may be left in an inaccessible, partially written state.

Reproduction

1. Configure and use @sourcebot/mcp with SOURCEBOT_HOST but without a valid SOURCEBOT_API_KEY.
2. Ensure anonymous access is enabled so /api/chat/blocking still runs through withOptionalAuthV2.
3. Call ask_codebase.
4. Open the returned session link (for example: https://<host>/~/chat/<id>).
5. The chat page returns 404.

Observed DB State

Example row from Chat:

• id = cmlfbak260009mm5wqa24udre
• visibility = PRIVATE
• createdById = NULL
• messages = []
• name = NULL

Expected Behavior

• Either the created chat should be readable at the returned URL, or
• the API should fail early instead of returning an unusable link.

Suspected Root Cause

/api/chat/blocking creates chats as PRIVATE unconditionally while also allowing createdById to be null:

• packages/web/src/app/api/(server)/chat/blocking/route.ts
  • createdById: user?.id
  • visibility: ChatVisibility.PRIVATE

Read access later checks:

• packages/web/src/features/chat/actions.ts (getChatInfo):
  • if (chat.visibility === ChatVisibility.PRIVATE && chat.createdById !== user?.id) return notFound();

For unauthenticated viewers (or any user), that private/null-owner chat fails access checks and /[domain]/chat/[id] returns notFound():

• packages/web/src/app/[domain]/chat/[id]/page.tsx

Secondary Symptom

The same visibility/owner check likely prevents later writes in blocking flow (updateChatMessages, updateChatName), which explains empty messages and null name.

Possible Fix

Align blocking chat creation with createChat behavior:

• In packages/web/src/app/api/(server)/chat/blocking/route.ts, set:
  • visibility: user ? ChatVisibility.PRIVATE : ChatVisibility.PUBLIC
• Or enforce authenticated identity for /api/chat/blocking and return 401 when unauthenticated.

If the first option is chosen, also confirm the returned chatUrl behavior for public chats and update tests.

Suggested Tests

• Add API test for /api/chat/blocking with unauthenticated context and anonymous access enabled.
• Verify created chat visibility/owner fields are coherent.
• Verify returned chatUrl opens successfully.
• Verify messages and generated chat name are persisted.