Summary

• Problem: cron delivery inference rebuilt LINE targets from normalized session keys, so line group/user IDs could lose their required uppercase recipient prefix before push delivery.
• Why it matters: LINE push delivery uses the webhook userId, groupId, or roomId as the to recipient; lowercased IDs are rejected by the LINE API, which matches the silent delivery failures reported in [Bug]: [core] LINE delivery-recovery sends wrong recipient (lowercased / session-key prefix kept), causing silent push failures #81628.
• What changed: cron session-key inference now preserves raw peer casing where possible and repairs LINE U/C/R recipient prefixes when the canonical session key has already been lowercased.
• What did NOT change (scope boundary): no changes to LINE auth, outbound queue recovery mechanics, message rendering, or non-LINE target normalization.

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 [Bug]: [core] LINE delivery-recovery sends wrong recipient (lowercased / session-key prefix kept), causing silent push failures #81628
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior addressed: creating an agent-turn cron job from a LINE group session key infers a LINE delivery target with the uppercase C recipient prefix preserved instead of sending the lowercased session-key fragment.
• Real environment tested: local OpenClaw checkout on macOS, Node 22, after pnpm install, using the actual createCronTool implementation and a captured Gateway RPC call.
• Exact steps or command run after this patch:

node --import tsx - <<'NODE'
import { createCronTool } from './src/agents/tools/cron-tool.ts';

let captured;
const tool = createCronTool(
  { agentSessionKey: 'agent:main:line:group:c0123456789abcdef0123456789abcdef' },
  {
    callGatewayTool: async (method, _opts, params) => {
      captured = { method, params };
      return { ok: true, id: 'cron-line-target-proof' };
    },
  },
);

await tool.execute('line-target-proof', {
  action: 'add',
  job: {
    name: 'line target proof',
    schedule: { at: new Date(123).toISOString() },
    payload: { kind: 'agentTurn', message: 'prove LINE target casing' },
  },
});

console.log(JSON.stringify({
  gatewayMethod: captured?.method,
  inferredDelivery: captured?.params?.delivery,
}, null, 2));
NODE

• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

{
  "gatewayMethod": "cron.add",
  "inferredDelivery": {
    "mode": "announce",
    "to": "C0123456789abcdef0123456789abcdef",
    "channel": "line"
  }
}

• Observed result after fix: the cron job creation path sends cron.add with delivery.to set to C0123456789abcdef0123456789abcdef, preserving the case-sensitive LINE recipient prefix that LINE expects for group push delivery.
• What was not tested: no live LINE API push was run because this environment does not have a LINE channel access token or real group ID; the lower-level LINE send and recovery paths were covered by the local regression suite below.
• Before evidence (optional but encouraged): [Bug]: [core] LINE delivery-recovery sends wrong recipient (lowercased / session-key prefix kept), causing silent push failures #81628 includes failed delivery queue entries with lowercase to values and LINE API 400 responses for lowercase recipients.

Root Cause (if applicable)

• Root cause: cron delivery fallback parsed agent session keys through a lowercasing parser and then used the parsed peer fragment directly as delivery.to. LINE recipient IDs are case-sensitive, so a session key such as agent:main:line:group:c... could produce an invalid lowercase c... push target.
• Missing detection / guardrail: cron target inference had Telegram and Matrix coverage, but no LINE-specific regression for case-sensitive U/C/R IDs or prefixed LINE targets.
• Contributing context (if known): LINE webhook source IDs are the documented push recipients: user IDs, group IDs, and room IDs from the event source are used as the to value for push messages.

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/agents/tools/cron-tool.test.ts
• Scenario the test should lock in: LINE cron fallback restores uppercase U/C/R recipient prefixes and strips line:*: target prefixes before populating inferred delivery.
• Why this is the smallest reliable guardrail: the bug is introduced at cron session-key-to-delivery inference before delivery reaches the LINE plugin.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Long-running LINE cron/agent-turn announcements inferred from a LINE session key now target the case-correct LINE recipient ID instead of an invalid lowercase recipient.

Diagram (if applicable)

Before:
agent:main:line:group:c... -> cron delivery.to="c..." -> LINE push rejects recipient

After:
agent:main:line:group:c... -> cron delivery.to="C..." -> LINE push receives case-correct recipient

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: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22, pnpm 11.1.0
• Model/provider: N/A
• Integration/channel (if any): LINE cron delivery inference
• Relevant config (redacted): no secrets or live LINE config used

Steps

1. Create an agent-turn cron job through createCronTool with agentSessionKey="agent:main:line:group:c0123456789abcdef0123456789abcdef" and no explicit delivery target.
2. Capture the cron.add Gateway params produced by the tool.
3. Inspect delivery.to.

Expected

• delivery.to keeps LINE's uppercase recipient prefix, e.g. C0123456789abcdef0123456789abcdef.

Actual

• Before this patch, cron inference could use the lowercased session-key peer fragment as the target.
• After this patch, the captured cron.add params contain the uppercase C... LINE target.

Evidence

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

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • LINE group session key infers delivery.to with uppercase C.
  • LINE user/direct session key infers delivery.to with uppercase U.
  • Prefixed line:group:C... peer fragments are stripped before inferred delivery.
  • Adjacent LINE send/context/recovery and outbound delivery tests still pass.
  • check:changed --base upstream/main passes for the touched core/core-test lanes.
  • pnpm build completes successfully.
• Edge cases checked: prefixed LINE target fragments, direct/user IDs, group IDs, Telegram direct-thread inference remains covered by existing tests.
• What you did not verify: live LINE Messaging API push with a real channel access token.

Validation commands run locally:

node scripts/run-vitest.mjs src/agents/tools/cron-tool.test.ts
node scripts/run-vitest.mjs extensions/line/src/send.test.ts extensions/line/src/channel.sendPayload.test.ts extensions/line/src/bot-message-context.test.ts extensions/line/src/monitor-durable.test.ts extensions/line/src/auto-reply-delivery.test.ts src/agents/tools/cron-tool.test.ts src/infra/outbound/delivery-queue.recovery.test.ts src/infra/outbound/deliver.test.ts
pnpm check:changed --base upstream/main
pnpm build

Results:

cron-tool focused run: 2 files passed, 164 tests passed
expanded LINE/outbound run: 9 files passed, 316 tests passed
check:changed --base upstream/main: passed
pnpm build: passed

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: N/A

Risks and Mitigations

• Risk: changing session-key inference could affect other case-sensitive providers.
  • Mitigation: raw peer casing is preserved when present, and the LINE-specific repair only applies when channel === "line".