Description

In agentHandlers.agent.invoke, the gateway will honor a caller-supplied request.sessionId (requestedSessionId) and use it as the effective sessionId for the run when either:

• the session key has no existing entry (!entry?.sessionId), or
• the existing session is considered fresh (canReuseSession)

This makes sessionId effectively client-controlled for new/fresh sessions.

Why this is a security issue (in multi-user / multi-tenant deployments):

• sessionId is the identifier used to locate the underlying transcript file on disk (via resolveSessionFilePath(...) in other code paths).
• Because the transcript path is derived from sessionId (not from an authenticated principal), a malicious client who learns/guesses another user’s sessionId can supply it and cause the agent run to load/append to the victim’s transcript.
• The gateway also persists this chosen sessionId into the session store entry for the chosen sessionKey, potentially linking disparate identities and enabling continued access.

Vulnerable code:

const usableRequestedSessionId =
  requestedSessionId && (!entry?.sessionId || canReuseSession)
    ? requestedSessionId
    : undefined;
const sessionId = usableRequestedSessionId
  ? usableRequestedSessionId
  : ((canReuseSession ? entry?.sessionId : undefined) ?? randomUUID());

Even though session IDs are usually UUIDs, they can still be exposed through logs, client-side state, screenshots, shared links, or other leaks; once known, this becomes a direct conversation takeover primitive.

Recommendation

Do not allow unprivileged callers to choose the underlying transcript sessionId.

Options (choose one):

1. Strict binding (recommended): once a sessionKey exists, always require request.sessionId (if present) to equal the stored entry.sessionId; otherwise reject.

if (requestedSessionId && entry?.sessionId && requestedSessionId !== entry.sessionId) {
  respond(false, undefined, errorShape(ErrorCodes.INVALID_REQUEST, "sessionId does not match sessionKey"));
  return;
}
const sessionId = entry?.sessionId ?? randomUUID();

2. Privileged override only: only honor request.sessionId for trusted/internal callers (e.g., owner/admin scope), and validate it with validateSessionId() before use.

3. Derive sessionId server-side: ignore client-provided sessionId entirely for gateway requests; use server-generated IDs and expose them via responses if clients need to resume.

Additionally, consider binding sessions to an authenticated principal (tenant/user) and enforcing authorization on any request that specifies a sessionKey.

Description

In agentCommandInternal, the code persists session overrides whenever sessionStore && sessionKey and unconditionally sets lastInteractionAt to now.

This undermines the new lifecycle behavior (introduced elsewhere in this diff) that intends cron/heartbeat/internal system events not to keep sessions alive:

• updateSessionStoreAfterAgentRun() now supports touchInteraction: false for cron/heartbeat/internal events and will avoid updating lastInteractionAt.
• However, the earlier override-persistence block in agent-command.ts writes lastInteractionAt: now regardless of run kind or whether any explicit override was actually provided.

Impact:

• Non-interactive runs that still reach this code path can refresh lastInteractionAt, preventing idle resets/compaction policies from triggering.
• This can prolong retention of prior conversation context beyond intended limits, increasing risk of cross-turn privacy leaks (stale context reused longer than expected).

Vulnerable code:

const next: SessionEntry = {
  ...entry,
  sessionId,
  updatedAt: now,
  sessionStartedAt: entry.sessionStartedAt ?? now,
  lastInteractionAt: now,
};

Recommendation

Only update lastInteractionAt when the run represents a real user interaction (or when an explicit override is actually present), and ensure cron/heartbeat/internal event runs cannot touch it.

For example:

const now = Date.now();
const hasExplicitOverride = Boolean(thinkOverride || verboseOverride /* || other overrides */);
const shouldTouchInteraction =
  hasExplicitOverride &&
  opts.bootstrapContextRunKind !== "cron" &&
  opts.bootstrapContextRunKind !== "heartbeat" &&
  !opts.internalEvents?.length;

const next: SessionEntry = {
  ...entry,
  sessionId,
  updatedAt: now,
  sessionStartedAt: entry.sessionStartedAt ?? now,
  lastInteractionAt: shouldTouchInteraction ? now : entry.lastInteractionAt,
};

Alternatively, gate the entire persistence block behind hasExplicitOverride if it is intended only for explicit /command overrides.

Description

In agent gateway handler, the decision to advance lastInteractionAt is based on request fields bootstrapContextRunKind and internalEvents.

• Both fields are accepted from the client request (present in the public RPC schema with additionalProperties: false), so an external caller can set them arbitrarily.
• The handler uses these fields to compute touchInteraction. If touchInteraction is false, lastInteractionAt is not updated.
• This allows a caller to influence session freshness tracking:
  • Set bootstrapContextRunKind to "heartbeat"/"cron" or provide any internalEvents to suppress lastInteractionAt updates, making the session appear idle and potentially triggering unexpected resets/rollovers.
  • Conversely, omit these fields (or set bootstrapContextRunKind: "default" and no internalEvents) to ensure lastInteractionAt is updated, potentially keeping a session “fresh” when it should not be.

Vulnerable code:

const touchInteraction =
  request.bootstrapContextRunKind !== "cron" &&
  request.bootstrapContextRunKind !== "heartbeat" &&
  !request.internalEvents?.length;
...
lastInteractionAt: touchInteraction ? now : entry?.lastInteractionAt,

If multiple principals can call the same agent/session key (e.g., shared/global sessions), this becomes a session-lifecycle tampering vector that can impact other users by forcing unexpected resets or preventing expected resets.

Recommendation

Do not trust client input for lifecycle bookkeeping flags.

• Derive bootstrapContextRunKind and internalEvents from server-side context (e.g., cron scheduler / heartbeat subsystem), not from the external RPC payload.
• If these fields must remain in the API, enforce authorization and validate them against the authenticated caller type (e.g., only allow "cron"/"heartbeat" from internal/system clients).

Example (conceptual):

const isInternalCaller = client?.connect?.client?.id === GATEWAY_CLIENT_IDS.SYSTEM;
const runKind = isInternalCaller ? request.bootstrapContextRunKind : "default";
const internalEvents = isInternalCaller ? request.internalEvents : undefined;

const touchInteraction = runKind !== "cron" && runKind !== "heartbeat" && !internalEvents?.length;

This prevents external callers from manipulating lastInteractionAt and session freshness behavior.

Description

readSessionHeaderStartedAtMs() reads the first JSONL line of the transcript and uses header.timestamp as the authoritative sessionStartedAt fallback for legacy session rows (missing sessionStartedAt). This value then influences daily reset freshness (evaluateSessionFreshness() uses sessionStartedAt).

If an attacker can modify/delete/recreate transcript files (e.g., due to group-writable state dir, misconfigured OPENCLAW_STATE_DIR, or a compromised local plugin/process running under the same account), they can forge the transcript header timestamp:

• Future timestamp → keep a session “fresh” across daily resets, causing unintended session reuse/retention.
• Old timestamp → force frequent resets (availability/UX impact).

Vulnerable code:

return parseTimestampMs(header.timestamp);

There is no plausibility check (e.g., rejecting timestamps far in the future relative to now), and the code treats the transcript header as trusted input.

Recommendation

Treat transcript header timestamps as untrusted and apply sanity bounds before using them for lifecycle decisions.

Suggested hardening:

• Pass now into the resolver and reject timestamps outside a reasonable window (e.g., older than some max history if desired, and newer than now + allowedClockSkewMs).
• Prefer store-managed timestamps when available; only use transcript header as a best-effort fallback.
• Consider enforcing secure directory permissions (e.g., 0700) for the state/sessions directories during creation or via a startup audit.

Example:

function clampHeaderTimestampMs(ts: number | undefined, now: number): number | undefined {
  if (ts == null) return undefined;
  const maxFutureSkewMs = 5 * 60_000;
  if (ts > now + maxFutureSkewMs) return undefined;
  return ts;
}

​// ...
const parsed = parseTimestampMs(header.timestamp);
return clampHeaderTimestampMs(parsed, Date.now());