PR #69529: fix: prevent defaultAccountId leak in cross-provider message sends

• Repository: openclaw/openclaw
• Author: hszhsz
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/69529

Description (problem / solution / changelog)

Summary

Two bug fixes bundled in this PR:

Fix 1: #69525 — Cross-provider message send leaks source session accountId to target channel

When sending messages across providers (e.g. Telegram → Feishu) with allowAcrossProviders: true, the source session's defaultAccountId was incorrectly propagated to the target channel plugin, which has no account registered under that name.

File: src/infra/outbound/message-action-runner.ts

const explicitlyProvidedAccountId = readStringParam(params, "accountId");
const allowAcrossProviders = cfg.tools?.message?.crossContext?.allowAcrossProviders === true;
const isCrossProvider = Boolean(
  allowAcrossProviders &&
    input.toolContext?.currentChannelProvider &&
    input.toolContext.currentChannelProvider !== channel,
);
let accountId = explicitlyProvidedAccountId ?? (isCrossProvider ? undefined : input.defaultAccountId);

Fix 2: #69482 — Telegram "Allow always" source field rejected by gateway

Telegram "Allow always" approval handler writes source: "allow-always", but the gateway schema for exec.approvals.set didn't include this field, causing openclaw approvals set --gateway to reject entries with unexpected property 'source'.

File: src/gateway/protocol/schema/exec-approvals.ts

Added source: Type.Optional(Type.String()) to ExecApprovalsAllowlistEntrySchema.

Also included: #69475 (partial) — Skill description fixes

Updated SKILL.md description fields for gog and session-logs to include Use when: trigger conditions per the Anthropic skill spec.

Files: skills/gog/SKILL.md, skills/session-logs/SKILL.md

Changed files

• skills/gog/SKILL.md (modified, +1/-1)
• skills/session-logs/SKILL.md (modified, +1/-1)
• src/gateway/protocol/schema/exec-approvals.ts (modified, +3/-0)
• src/infra/outbound/message-action-runner.test.ts (modified, +66/-0)
• src/infra/outbound/message-action-runner.ts (modified, +13/-1)

PR #2: fix(cron): validate announce account ids

• Repository: iamlukethedev/openclaw
• Author: iamlukethedev
• State: open | merged: False
• Link: https://github.com/iamlukethedev/openclaw/pull/2

Description (problem / solution / changelog)

Summary

• Problem: cron.add and cron.update validated announce channels but still accepted explicit delivery.accountId values that do not exist for the chosen channel.
• Why it matters: operators can create or patch cron jobs that look valid at write time but are guaranteed to fail or misroute at delivery time.
• What changed: src/gateway/server-methods/cron.ts now validates explicit announce accountId values against configured accounts for the resolved channel, including failure destinations that use announce mode.
• What did NOT change (scope boundary): delivery execution, account auto-resolution, and cron transport behavior were not changed; this is creation/update-time validation only.
• AI-assisted: Yes. I implemented the fix and ran the scoped verification locally in this workspace.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #69513
• Related #69482
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: cron request validation checked that announce delivery channels were configured, but it never checked whether an explicitly provided account id belonged to that configured channel.
• Missing detection / guardrail: gateway RPC tests covered channel validation but not invalid explicit announce account ids on add/update.
• Contributing context (if known): multi-account channels make this more likely because a typo still looks syntactically valid and gets persisted unchanged.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/gateway/server.cron.test.ts
• Scenario the test should lock in: cron.add and cron.update reject announce deliveries whose explicit accountId is not configured for the selected channel.
• Why this is the smallest reliable guardrail: the bug lives in gateway request validation, so the RPC test file exercises the real user-facing contract without needing full cron execution.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• openclaw cron create and equivalent gateway cron.add / cron.update calls now reject invalid explicit announce account ids instead of storing a broken delivery target.

Diagram (if applicable)

Before:
[cron add/update with announce channel + bad accountId] -> [stored successfully] -> [later delivery failure/misroute]

After:
[cron add/update with announce channel + bad accountId] -> [gateway validation rejects request] -> [operator fixes accountId before save]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: Ubuntu Linux in Cursor Cloud
• Runtime/container: Node 22 + pnpm workspace
• Model/provider: N/A
• Integration/channel (if any): Gateway cron RPC validation
• Relevant config (redacted): test config with Telegram announce channel enabled

Steps

1. Configure a channel with one valid account.
2. Call cron.add or cron.update with delivery.mode="announce", that channel, and a nonexistent accountId.
3. Observe gateway response.

Expected

• The gateway rejects the request before persisting the job.

Actual

• Before this fix, the gateway accepted and stored the invalid account id unchanged.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: ran pnpm test src/gateway/server.cron.test.ts; ran pnpm check:changed.
• Edge cases checked: add and update both reject invalid explicit announce account ids; existing announce channel validation remains intact.
• What you did not verify: live cron execution against a real multi-account channel deployment.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: configs that rely on implicit fallback behavior for malformed explicit account ids will now fail fast at write time.
  • Mitigation: validation only applies when an explicit non-empty accountId is provided; existing implicit/default-account flows are unchanged.

Changed files

• src/gateway/server-methods/cron.ts (modified, +78/-8)
• src/gateway/server.cron.test.ts (modified, +371/-0)

PR #3: fix(approvals): accept allow-always source metadata

• Repository: iamlukethedev/openclaw
• Author: iamlukethedev
• State: open | merged: False
• Link: https://github.com/iamlukethedev/openclaw/pull/3

Description (problem / solution / changelog)

Summary

• Problem: Telegram/native allow-always approvals already persist allowlist entries with source: "allow-always", but the gateway exec.approvals.set schema rejected that field as unexpected.
• Why it matters: local approvals files and the gateway push path disagree on the allowlist contract, so gateway sync can fail even when the on-disk approvals file is valid for the runtime.
• What changed: src/gateway/protocol/schema/exec-approvals.ts now accepts optional source: "allow-always" on allowlist entries, matching the existing persisted approvals type.
• What did NOT change (scope boundary): no approval decision logic, persistence behavior, or Telegram/native reply handling changed in this PR; it only aligns the gateway protocol schema with existing stored data.
• AI-assisted: Yes. I implemented the protocol fix and verified it locally with targeted tests and changed-scope checks.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #69482
• Related #69478
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the durable approvals store type and normalization path already preserved source: "allow-always", but the gateway protocol schema for exec.approvals.set and exec.approvals.node.set did not allow that field.
• Missing detection / guardrail: there was no validator regression test covering a real allowlist payload that included source: "allow-always".
• Contributing context (if known): the issue report shows this surfaced through Telegram "Allow always", but the mismatch is fundamentally between persisted approvals data and the gateway wire contract.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/gateway/protocol/index.test.ts
• Scenario the test should lock in: validateExecApprovalsSetParams and validateExecApprovalsNodeSetParams accept allowlist entries that include source: "allow-always".
• Why this is the smallest reliable guardrail: the bug is a protocol/schema rejection, so validator tests hit the exact contract boundary that failed without needing a live Telegram or gateway sync flow.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• Gateway approval set payloads may now include persisted allow-always source metadata without being rejected as invalid.

Diagram (if applicable)

Before:
[allowlist entry with source="allow-always"] -> [exec.approvals.set validator] -> [reject unexpected property]

After:
[allowlist entry with source="allow-always"] -> [exec.approvals.set validator] -> [accept payload]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: Ubuntu Linux in Cursor Cloud
• Runtime/container: Node 22 + pnpm workspace
• Model/provider: N/A
• Integration/channel (if any): Gateway exec approvals protocol validation
• Relevant config (redacted): approvals payload with allowlist entry { pattern: "/usr/bin/curl", source: "allow-always" }

Steps

1. Construct an approvals file payload containing an allowlist entry with source: "allow-always".
2. Validate it through the gateway protocol path for exec.approvals.set or exec.approvals.node.set.
3. Observe whether the validator accepts or rejects the payload.

Expected

• The gateway protocol should accept allowlist entries that match the already-persisted approvals type, including source: "allow-always".

Actual

• Before this fix, the schema rejected the payload because source was not part of ExecApprovalsAllowlistEntrySchema.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: ran pnpm test src/gateway/protocol/index.test.ts; ran pnpm check:changed.
• Edge cases checked: both gateway set and node set validators accept allow-always source metadata; no unrelated schema fields were broadened.
• What you did not verify: live Telegram approval flow or a real openclaw approvals set --gateway round-trip against a running gateway.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: this only fixes the schema mismatch slice of the issue; if another runtime path strips or mishandles source, that would need follow-up.
  • Mitigation: this PR is intentionally scoped to the concrete validator rejection, and the new tests lock the contract in place.

Changed files

• src/gateway/protocol/index.test.ts (modified, +45/-1)
• src/gateway/protocol/schema/exec-approvals.ts (modified, +1/-0)