PR #74142: fix(agents/tools): resolve sessionKey=current for channel-plugin clients

• Repository: openclaw/openclaw
• Author: poolside-ventures
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74142

Description (problem / solution / changelog)

Summary

• Problem: The session_status tool's docstring (tool-description-presets.ts:63) tells agents universally to pass sessionKey="current", but resolveCurrentSessionClientAlias only honors the alias for first-party UI client ids (TUI, CLI, WEBCHAT_UI, CONTROL_UI, MACOS_APP, IOS_APP, ANDROID_APP). Channel-plugin clients (Slack, Discord, Scope, ...) fall through, the literal "current" is never resolved to the requester, the literal-current store lookup and sessions.resolve("current") both find nothing, and the tool throws Unknown sessionKey: current. The agent retries with a constructed key, that fails too, and only then produces a final reply — costing ~4s per turn on date/time / model-status queries.
• Why it matters: The system prompt (system-prompt.ts:827) directs agents to call session_status for date/time questions. Every such question on a channel-plugin agent burns ~4s of failed tool calls before the agent gives up and answers from internal state. Repro and gateway log slice in #74141.
• What changed: Added a final fallback in session-status-tool.ts: when the literal-current store lookup AND resolveSessionReference both return nothing matching, treat "current" as the requester's own session. Sets resolvedViaImplicitCurrentFallback = true so visibility-target-as-self handling at :469-475 still works.
• What did NOT change (scope boundary): The existing prefer-literal-session-named-"current" feature documented by prefers a literal current session key in session_status and resolves a literal current sessionId in session_status — preserved by positioning the new fallback AFTER those paths. resolveCurrentSessionClientAlias itself — untouched, so resolveSessionReference's strict-alias semantics for non-UI clients are unchanged. The CURRENT_SESSION_CLIENT_ALIAS_IDS set — untouched. Other tools that take a sessionKey param (sessions_history, sessions_send, sessions_spawn, subagents) — those have their own resolution paths and aren't affected by this PR (separate fix if/when they hit the same class of issue).

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Skills / tool execution

Linked Issue/PR

• Closes #74141
• This PR fixes a bug or regression

Root Cause

resolveCurrentSessionClientAlias was designed for the case where a UI/CLI client passes its own client id (e.g., "openclaw-tui") as the sessionKey and the resolver translates that to the requester key. The literal alias "current" was not part of that contract — agents passing "current" were expected to be served by the deeper resolveSessionReference → sessions.resolve("current") path, which works if a real session is keyed literally "current" in the gateway.

That assumption holds for first-party UI clients (where the ACP gateway registers a session keyed by the client's session id and "current" happens to match in practice for TUI/CLI flows) but doesn't hold for channel-plugin clients. The docstring Use sessionKey="current" for the current session was added universally, ahead of the implementation actually supporting it universally — leaving channel-plugin agents to discover the gap at runtime.

Tests

• Added resolves sessionKey=current for a channel-plugin session via implicit fallback in src/agents/openclaw-tools.session-status.test.ts. Uses a channel-style requester key (agent:main:scope:scopy:direct:scopy) and asserts details.sessionKey is the requester key.
• All 116 existing tests in sessions-resolution.test.ts + openclaw-tools.session-status.test.ts pass unchanged.

Verification

$ pnpm vitest run \
    src/agents/tools/sessions-resolution.test.ts \
    src/agents/openclaw-tools.session-status.test.ts
 Test Files  4 passed (4)
      Tests  116 passed (116)

Changed files

• src/agents/openclaw-tools.session-status.test.ts (modified, +23/-0)
• src/agents/tools/session-status-tool.ts (modified, +23/-0)

PR #72306: fix(agents/tools): resolve sessionKey="current" for channel-plugin agents

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

Description (problem / solution / changelog)

Summary

• Problem: session_status's docstring tells agents to pass sessionKey="current", but the resolver only treats that alias as "the requester" for first-party UI clients (TUI, CLI, web/mobile). Channel-plugin agents (Slack, Discord, Scope, ...) hit Unknown sessionKey: current, retry with their constructed key (also misses the store), and burn ~4s per turn before giving up.
• Why it matters: The system prompt routes date/time and several status questions through session_status. Every one of those was paying the 4s tax on channel-plugin agents.
• What changed: After every existing fallback misses, treat sessionKey="current" as the requester's own session and return a status card backed by a minimal synthesized entry. The fallback is the very last step in the chain, gated strictly on the literal "current".
• What did NOT change: resolveCurrentSessionClientAlias and CURRENT_SESSION_CLIENT_ALIAS_IDS are untouched. Existing precedence for literal sessions/sessionIds named "current" is preserved (their tests still pass byte-identical). Other tools that take a sessionKey aren't touched.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Skills / tool execution

Linked Issue/PR

• Closes #74141
• This PR fixes a bug or regression

Root Cause

• Root cause: The docstring promised "current" worked universally, but the resolver only mapped it to the requester for a hard-coded set of UI client ids. Channel-plugin requesters whose session has not been written to the store yet have nothing to match.
• Missing detection / guardrail: No test exercised an unstored channel-style requester. Every existing current-related test happened to use a stored requester key.
• Contributing context (if known): resolveCurrentSessionClientAlias was originally for translating UI client labels like openclaw-tui into the requester key. The literal "current" was assumed to be served by the deeper sessions.resolve("current") path, which only works for first-party flows.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
• Target test or file: src/agents/openclaw-tools.session-status.test.ts
• Scenario the test should lock in: channel-style requester key + empty store + sessionKey: "current" resolves to the requester key instead of throwing.
• Why this is the smallest reliable guardrail: the existing test mocks already cover store, gateway resolve, and status-text rendering, so one new it(...) exercises the full path.
• Tests added in this PR:
  • resolves sessionKey=current for a channel-plugin requester via implicit fallback — the regression.
  • does not synthesize a current fallback for unknown non-literal session keys — gate proof; arbitrary unknown keys still throw.

User-visible / Behavior Changes

For channel-plugin agents whose session hasn't been persisted yet, session_status with sessionKey="current" now returns a usable status card (defaults from config, no transcript usage) instead of throwing. No change for agents whose session is already in the store, no change for first-party UI clients.

Diagram

N/A

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No. The synthesized entry is keyed to the requester's own key and goes through the existing visibilityGuard.check with resolvedViaImplicitCurrentFallback = true (treat-as-self) — the same path the existing implicit-default-direct fallback uses.

Repro + Verification

Environment

• OS: Linux x64
• Runtime: Node 22+
• Channel: any channel-plugin agent with a channel-style requester key (reporter confirmed against Scope, agent:scopy:scope:scopy:direct:scopy)

Steps

1. Run a gateway with a channel-plugin agent whose requester key is channel-style.
2. Send a message that triggers session_status (e.g. "What day is it today?").
3. Watch the gateway logs.

Expected

• session_status returns a status card on the first call, no retry loop.

Actual (before)

• Throws Unknown sessionKey: current, retries with the constructed key, throws again, ~4s wasted per turn.

Evidence

• Failing test/log before + passing after — pnpm test src/agents/openclaw-tools.session-status.test.ts src/agents/tools/sessions-resolution.test.ts → 60/60 passing. The new regression test fails on main with Unknown sessionKey: current and passes with this patch.
• Trace/log snippets — see #74141 for the gateway log slice.

Human Verification

• Verified scenarios:
  • Channel-style requester key + empty store + sessionKey: "current" → returns status card backed by the requester key.
  • Channel-style requester key + empty store + non-"current" key → still throws Unknown sessionId.
  • Literal session named current in the store → still preferred over the synthetic fallback.
  • Literal sessionId "current" in the store → still preferred.
  • Subagent requester + "current" → still binds to the subagent session.
  • First-party UI alias (openclaw-tui) → unchanged.
• Edge cases checked: empty/blank storeScopedRequesterKey short-circuits the fallback to null so the original throw still fires.
• What I did not verify: live end-to-end on a real channel plugin (no local Scope/Slack/Discord environment). The unit test covers the exact resolution chain the live repro hit.

Changed files

• src/agents/openclaw-tools.session-status.test.ts (modified, +93/-0)
• src/agents/tools/session-status-tool.ts (modified, +47/-3)