feat: add queue-if-busy behavior and hub publishing to POST /v1/messages

[awlevin]

Summary

PR 1/6 in the remove-runs-centralize-messages plan (cherry-picked to main).

• POST /v1/messages now queues messages when the session is busy instead of returning 409
• Events are published to assistantEventHub so SSE subscribers can observe responses
• Returns 202 { accepted: true } in both immediate and queued cases

Plan: .private/plans/REMOVE_RUNS_CENTRALIZE_MESSAGES.md

---

[devin-ai-integration]

Devin Review found 2 potential issues.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🔴 New sendMessageDeps path bypasses secret ingress check, allowing secrets to reach model context

The new sendMessageDeps code path in handleSendMessage skips the checkIngressForSecrets check that every other message ingress path performs. When secretDetection.blockIngress is enabled, user messages containing detected secrets (API keys, passwords, etc.) will be persisted and sent to the LLM without being blocked.

Security Impact and Root Cause

Both persistAndProcessMessage (assistant/src/daemon/server.ts:690-692) and processMessage (assistant/src/daemon/server.ts:737-739) call checkIngressForSecrets(content) before processing the message:

const ingressCheck = checkIngressForSecrets(content);
if (ingressCheck.blocked) {
  throw new IngressBlockedError(ingressCheck.userNotice!, ingressCheck.detectedTypes);
}

The new sendMessageDeps path at assistant/src/runtime/routes/conversation-routes.ts:243-279 directly calls session.persistUserMessage() and session.runAgentLoop() without any secret scanning. This means any secret embedded in user content will be persisted to the database and sent to the LLM provider, defeating the secret detection security feature.

Impact: Secrets (API keys, passwords, tokens) in user messages bypass the ingress filter and are sent to the LLM provider, potentially leaking sensitive credentials.

Prompt for agents

In assistant/src/runtime/routes/conversation-routes.ts, add a secret ingress check at the beginning of the sendMessageDeps code path (around line 243, after the `if (deps.sendMessageDeps)` check). Import `checkIngressForSecrets` from '../../security/secret-ingress.js' and add:

const ingressCheck = checkIngressForSecrets(content ?? '');
if (ingressCheck.blocked) {
  return Response.json(
    { error: ingressCheck.userNotice ?? 'Message blocked by secret detection' },
    { status: 400 },
  );
}

This should be placed before the session.isProcessing() check so that secrets are blocked regardless of whether the message would be queued or processed immediately.

---

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

[devin-ai-integration]

🔴 New sendMessageDeps path does not configure session properties (channelCapabilities, assistantId, turnChannelContext)

The new sendMessageDeps code path skips critical session configuration that the legacy paths perform before persisting and processing a message. This causes the agent loop to run without channel capabilities, assistant ID, or turn channel context.

Missing Session Configuration Details

Both persistAndProcessMessage and processMessage in assistant/src/daemon/server.ts:701-709 configure the session before running the agent loop:

session.setAssistantId(options?.assistantId ?? 'self');
session.setGuardianContext(options?.guardianContext ?? null);
session.setChannelCapabilities(resolveChannelCapabilities(sourceChannel));
session.setCommandIntent(options?.commandIntent ?? null);
const resolvedChannel = resolveTurnChannel(sourceChannel, options?.transport?.channelId);
session.setTurnChannelContext({
  userMessageChannel: resolvedChannel,
  assistantMessageChannel: resolvedChannel,
});

The new path at assistant/src/runtime/routes/conversation-routes.ts:243-279 calls session.persistUserMessage() and session.runAgentLoop() without any of these configuration calls. This means:

1. channelCapabilities is not set, so the agent loop may not know what the channel supports (e.g., rich formatting, inline buttons)
2. assistantId is not set to 'self', leaving it as whatever value it had from a previous turn (or undefined)
3. turnChannelContext is not set, so persistUserMessage won't record the channel metadata on the persisted message, and conversationStore.setConversationOriginChannelIfUnset won't be called

Impact: Messages processed via the new path will lack proper channel context, potentially causing incorrect formatting of assistant responses and missing origin channel tracking. The sourceChannel parsed from the request body (line 193) is validated but never used in the new path.

Prompt for agents

In assistant/src/runtime/routes/conversation-routes.ts, after obtaining the session on line 245 and before the isProcessing() check on line 252, add session configuration calls similar to what the legacy paths do in assistant/src/daemon/server.ts:701-709. You will need to:

1. Import resolveChannelCapabilities and resolveTurnChannel from the appropriate module (check server.ts imports)
2. Add the following configuration before line 252:

   session.setAssistantId('self');
   session.setChannelCapabilities(resolveChannelCapabilities(sourceChannel));
   const resolvedChannel = resolveTurnChannel(sourceChannel);
   session.setTurnChannelContext({
     userMessageChannel: resolvedChannel,
     assistantMessageChannel: resolvedChannel,
   });

Note: sourceChannel is already parsed and validated earlier in the function (line 193) but is never used in the sendMessageDeps path. The same configuration should also be applied for the queued message path, possibly by passing metadata to enqueueMessage so the session can be configured when the queued message is eventually processed.

---

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: ea4638a65a

ℹ️ 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]

Restore ingress secret checks for POST /v1/messages

When sendMessageDeps is present, this new branch bypasses DaemonServer.persistAndProcessMessage and calls session.persistUserMessage/enqueueMessage directly, so checkIngressForSecrets(...) is never executed for /v1/messages. Because daemon/lifecycle.ts now always wires sendMessageDeps, requests that include secrets (with default secretDetection.enabled=true and blockIngress=true) will be accepted and sent into model context instead of being rejected as IngressBlockedError (422), which is a security regression.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve sourceChannel context before persisting messages

The new sendMessageDeps path parses sourceChannel but never applies it to the session before persisting/queueing. In the previous path, persistAndProcessMessage set channel capabilities and turn channel context from sourceChannel; now calls like this persist without metadata/context, so non-macos requests can inherit stale context or fall back to macos channel behavior during runAgentLoop, causing incorrect channel-specific routing/capability behavior.

Useful? React with 👍 / 👎.