Summary

Original issue was closed without fix

Webhook-triggered agent runs always start a new session and lose conversation history/context, even when providing the same stable sessionKey and allowing it in config.

Steps to reproduce

1. Configure gateway with hooks.allowRequestSessionKey: true and (optionally) hooks.allowedSessionKeyPrefixes for your webhook agent.
2. POST repeatedly to /hooks/agent with

• The same sessionKey
• The same agentId (if needed)
• allowRequestSessionKey and allowedSessionKeyPrefixes set to permit your sessionKey value.

1. Observe: every POST triggers a fresh agent session (no preservation of message history or agent context).

Expected behavior

Subsequent webhook invocations with the same sessionKey should preserve conversation context. Agent state/history should persist across webhook calls, matching other channels.

Actual behavior

Every webhook call creates a brand new sessionId no matter what sessionKey is provided, despite config allowing sessionKey reuse. No prior conversation history or state is available to the agent. Reviewing src/cron/isolated-agent/run.ts reveals forceNew: true is always hardcoded for isolated agent runs, bypassing sessionKey-based continuity.

OpenClaw version

2026.2.26 (and recent main branch)

Operating system

Any (tested on Linux, macOS)

Install method

Any (docker, dev, app builds all affected)

Logs, screenshots, and evidence

See src/cron/isolated-agent/run.ts and src/cron/isolated-agent/session.ts:

// In run.ts
forceNew: params.job.sessionTarget === "isolated"
// In session.ts
if (!params.forceNew && entry?.sessionId) {...} else { sessionId = crypto.randomUUID(); }

This means session reuse logic is always bypassed for webhook agent turns, regardless of sessionKey value or freshness.

Impact and severity

Affected: Anyone using webhook agent endpoints who relies on persistent session context Severity: Serious, blocks agent stateful automations on webhooks Frequency: 100% on webhook agent runs Consequence: Webhooks cannot preserve conversation history/context across runs. Only concurrency and metadata are scoped by sessionKey, not agent state.

Additional information

This appears to be a regression from the originally intended fix for #18027. Configuration allows the request, but current code logic hardcodes session resets for all isolated agent runs, providing no workaround for webhook stateful flows. There is no apparent config setting or payload option to bypass the forced new session; upstream patch is needed.