fix(gateway): use resolved runtime config for message actions by KatTate · Pull Request #81477 · openclaw/openclaw

KatTate · 2026-05-13T16:28:02Z

Summary

use the active runtime config snapshot for gateway message.action send resolution instead of the legacy secrets-runtime wrapper
propagate matching resolved runtime configs into durable and direct outbound message sends while preserving explicit per-call configs when no source snapshot exists
keep package-stable non-secret auth markers for Codex app-server and GCP Vertex credentials when bundled plugin manifests are absent

Validation

pnpm exec oxfmt --check --threads=1 src/agents/model-auth-markers.ts src/agents/model-auth-markers.test.ts src/gateway/server-methods/send.ts src/gateway/server-methods/send.test.ts src/channels/message/send.ts src/channels/message/send.test.ts src/infra/outbound/message.ts src/infra/outbound/message.test.ts
OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test src/agents/model-auth-markers.test.ts src/gateway/server-methods/send.test.ts src/infra/outbound/message.test.ts src/channels/message/send.test.ts -- --run
pnpm build
added-line static scan for hardcoded secret assignments and shell/eval patterns: no findings

Runtime contract

Source-shaped SecretRef config stays on control-plane paths. Matching source configs upgrade to the resolved runtime snapshot on actual send paths. Explicit per-call configs remain explicit when runtime source snapshot data is unavailable, matching the existing plugin-tool runtime selection contract.

clawsweeper · 2026-05-13T16:31:26Z

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Close: the useful SecretRef-backed message-action fix is superseded by the narrower open replacement at #84535, while this branch still changes broader send/poll paths and lacks real behavior proof.

Canonical path: Use #84535 as the canonical message-action SecretRef fix; split any direct-send or auth-marker work only if a separate repro proves it is needed.

So I’m closing this here and keeping the remaining discussion on #84535.

Review details

Best possible solution:

Use #84535 as the canonical message-action SecretRef fix; split any direct-send or auth-marker work only if a separate repro proves it is needed.

Do we have a high-confidence way to reproduce the issue?

Yes for the underlying bug: #84530 gives concrete live Discord SecretRef channel-info steps and logs, and the source path shows message.action dispatch uses the selected cfg. I did not run a live repro in this read-only review.

Is this the best way to solve the issue?

No. This branch is broader than the confirmed failure and skips source matching in the shared gateway resolution path; the narrower replacement PR is the more maintainable solution.

Security review:

Security review needs attention: The diff changes secrets/runtime config selection and can route message actions or sends through a mismatched active credential snapshot.

[medium] Mismatched runtime snapshot can select wrong credentials — src/gateway/server-methods/send.ts:134
The gateway change prefers the active runtime config without checking that its source config matches the request context, so a stale snapshot can supply resolved credentials for a different config before dispatch.
Confidence: 0.86

What I checked:

Current gateway config seam: Current main resolves gateway send, poll, and message.action channel config from GatewayRequestContext.getRuntimeConfig() through applyPluginAutoEnable, so this is a shared hot path rather than a message-action-only seam. (src/gateway/server-methods/send.ts:134, 38e1654e0988)
PR branch broadens shared resolution: The latest PR patch changes resolveRequestedChannel to prefer getRuntimeConfigSnapshot() whenever present, which affects message.action, send, and poll before target/action dispatch and does not source-match the active snapshot against the request context. (src/gateway/server-methods/send.ts:132, b409d9229595)
Canonical replacement is narrower: The replacement PR at fix(gateway): resolve message actions against runtime config #84535 is open, explicitly relates this PR, limits the runtime snapshot lookup to gateway message.action, uses selectApplicableRuntimeConfig against config/sourceConfig, covers stale-snapshot fallback, and asserts ordinary send does not read the active runtime snapshot. (src/gateway/server-methods/send.ts:188, 08e4e8855e75)
Underlying bug is tracked separately: The related live report at [Bug]: Discord channel-info fails for SecretRef-backed named account while send works #84530 documents Discord channel-info failing for a SecretRef-backed named account while ordinary sends and inbound delivery work; the replacement PR closes that issue and includes redacted live Discord proof.
History points to the shared gateway path: Blame on the pre-PR mainline shows resolveRequestedChannel and message.action dispatch are shared across several gateway changes, with context config selection and auto-enable behavior carried through this file rather than a Discord-only action helper. (src/gateway/server-methods/send.ts:134, c3e5d85ce1df)

Likely related people:

steipete: Blame on the older mainline shows Peter Steinberger introduced and later refactored much of resolveRequestedChannel and the request-context runtime-config selection in the gateway send method. (role: feature-history owner; confidence: medium; commits: 296b19e41385, 7f3f108521f4; files: src/gateway/server-methods/send.ts)
Marcus Castro: Blame ties the message.action dispatch block that receives cfg and forwards it to dispatchChannelMessageAction to Marcus Castro's gateway routing work. (role: adjacent gateway contributor; confidence: medium; commits: aaae1aeb8f56; files: src/gateway/server-methods/send.ts)
Takhoffman: Blame shows the applyPluginAutoEnable selection around the shared channel-resolution config came from Tak Hoffman's gateway send regression fix. (role: adjacent owner of auto-enable selection; confidence: medium; commits: ff348d20636d; files: src/gateway/server-methods/send.ts)
Gio Della-Libera: Current-main blame for the gateway send and runtime snapshot files points to Gio Della-Libera's recent refactor that now owns the checked-out line provenance. (role: recent area contributor; confidence: low; commits: 056378efd582; files: src/gateway/server-methods/send.ts, src/config/runtime-snapshot.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 38e1654e0988.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3b30213361

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-05-13T16:31:31Z

+  const activeSecretsRuntimeConfig = getActiveSecretsRuntimeSnapshot()?.config;
  const cfg = applyPluginAutoEnable({
-    config: params.context.getRuntimeConfig(),
+    config: activeSecretsRuntimeConfig ?? params.context.getRuntimeConfig(),


Avoid cloning the full secrets snapshot on sends

In the gateway runtime this helper runs for both message.action and send, and an active secrets snapshot is present after startup. getActiveSecretsRuntimeSnapshot() deep-clones sourceConfig, config, every authStore, and webTools before returning, so each outbound message now pays O(config + auth stores) CPU/memory just to read the config (src/secrets/runtime.ts:81 and src/secrets/runtime.ts:476). Use the already pinned runtime config/context or add a config-only accessor so the hot send path does not clone all auth profile stores per request.

Useful? React with 👍 / 👎.

clawsweeper · 2026-05-23T21:18:22Z

ClawSweeper applied the proposed close for this PR.

Action: closed this PR.
Close reason: duplicate or superseded.
Evidence: durable ClawSweeper review.

openclaw-barnacle Bot added triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. gateway Gateway runtime size: S labels May 13, 2026

chatgpt-codex-connector Bot reviewed May 13, 2026

View reviewed changes

clawsweeper Bot added the mantis: telegram-visible-proof Mantis should capture Telegram visible proof. label May 13, 2026

This was referenced May 20, 2026

[Bug]: Discord channel-info fails for SecretRef-backed named account while send works #84530

Closed

fix(gateway): resolve message actions against runtime config #84535

Merged

KatTate requested a review from a team as a code owner May 23, 2026 20:56

openclaw-barnacle Bot added agents Agent runtime and tooling size: M and removed size: S labels May 23, 2026

KatTate and others added 2 commits May 23, 2026 15:57

fix(gateway): use resolved runtime config for message actions

6bd9eb5

Preserve runtime config for SecretRef message sends

b409d92

KatTate force-pushed the fix/message-action-secretref-runtime-config branch from 8a45661 to b409d92 Compare May 23, 2026 21:02

clawsweeper Bot closed this May 23, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(gateway): use resolved runtime config for message actions#81477

fix(gateway): use resolved runtime config for message actions#81477
KatTate wants to merge 2 commits into
openclaw:mainfrom
KatTate:fix/message-action-secretref-runtime-config

KatTate commented May 13, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 13, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 13, 2026

Uh oh!

clawsweeper Bot commented May 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KatTate commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Validation

Runtime contract

Uh oh!

clawsweeper Bot commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 13, 2026

Choose a reason for hiding this comment

Uh oh!

clawsweeper Bot commented May 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

KatTate commented May 13, 2026 •

edited

Loading

clawsweeper Bot commented May 13, 2026 •

edited

Loading