M2: Chat-intent for request access (non-member)

[NgoHarrison]

When a non-member messages the assistant, in addition to the existing deny reply, the system now notifies the guardian that someone is requesting access. Creates a guardian approval request and emits a notification signal.

Closes #9435
Part of #9432

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🔴 Access-request approval records pollute guardian approval interception, swallowing the guardian's normal messages

When a non-member messages the assistant and a guardian binding exists, notifyGuardianOfAccessRequest creates an approval request row in channelGuardianApprovalRequests with a synthetic conversationId like access-req-telegram-user-unknown-456. This record is returned by getAllPendingApprovalsByGuardianChat (which does not filter by toolName) when the guardian later sends any message to their chat.

How the guardian's messages get swallowed

The approval interception flow in guardian-approval-interception.ts:138-148 calls getAllPendingApprovalsByGuardianChat to find pending approvals for the guardian's chat. The new ingress_access_request approval rows are included in these results because the query only filters on channel, guardianChatId, status, and expiresAt — not on toolName (channel-guardian-store.ts:955-981).

When only the access-request approval is pending (the most common case), it becomes the sole guardianApproval at line 141. The guardian's message is then routed into the approval decision flow. Since the synthetic conversationId (access-req-...) has no corresponding pending interaction registered in the pending-interactions tracker, handleChannelDecision (channel-approvals.ts:133-134) returns { applied: false }. The interception code then returns { handled: true, type: 'stale_ignored' }, consuming the guardian's message without processing it normally.

This means any message the guardian sends while an access request is pending gets silently swallowed — the guardian cannot use the assistant normally. If a real tool approval is also pending alongside the access request, it may cause spurious disambiguation prompts or misdirected decisions.

Impact: Guardian is unable to interact with the assistant whenever a non-member access request is pending (up to 30 minutes per the TTL). All guardian messages are consumed by the approval interception flow and discarded as stale.

Prompt for agents

The ingress_access_request approval requests created by notifyGuardianOfAccessRequest are stored in the same channelGuardianApprovalRequests table as regular tool approval requests. The getAllPendingApprovalsByGuardianChat function in assistant/src/memory/channel-guardian-store.ts (line 955) does not filter by toolName, so these access request records are returned by the guardian approval interception flow in assistant/src/runtime/routes/guardian-approval-interception.ts (lines 112, 139, 231). This causes the guardian's normal messages to be intercepted and consumed as stale approval decisions.

To fix this, either:
1. Add a toolName exclusion filter to getAllPendingApprovalsByGuardianChat (and getPendingApprovalByGuardianChat) to exclude ingress_access_request rows, OR
2. Store access request notifications in a separate table or with a different status/type that is not queried by the approval interception flow, OR
3. Add filtering in guardian-approval-interception.ts to skip approval records where toolName is ingress_access_request when looking up guardian approvals.

Option 1 is the simplest: add a condition like ne(channelGuardianApprovalRequests.toolName, 'ingress_access_request') to the WHERE clauses in getPendingApprovalByGuardianChat (line 853), getAllPendingApprovalsByGuardianChat (line 963), and getPendingApprovalByRequestAndGuardianChat.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e548dc74e2

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Make access-request approvals resolvable by guardian decisions

This new access-request record is created without a requestId and points at a synthetic conversation ID, but guardian replies are applied through handleChannelDecision(conversationId, ...), which only succeeds when there is a pending interaction for that conversation. In practice, guardian approve/deny messages for ingress_access_request will not apply and the row stays pending until expiry, so the core approve/deny flow described by this change is non-functional.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Include guardian identity in access-request dedup lookup

The dedup query only keys on assistant/channel/requester/tool, so if guardian binding rotates while a request is still pending, subsequent messages from the same requester are suppressed as duplicates and no new request is created for the new guardian. Because decision handling enforces guardianExternalUserId ownership, the new guardian cannot act on the old request, leaving access requests blocked until expiry.

Useful? React with 👍 / 👎.