Description

In initSessionState, sessions that have a provider-owned CLI binding are forced to be treated as fresh whenever the session reset policy was not explicitly configured.

• The default/implicit daily reset is bypassed via skipImplicitExpiry.
• Because the session is treated as fresh, rollover logic (new session id, transcript archiving, state clearing) does not run.
• This can unintentionally create long-lived gateway sessions retaining chat transcripts and other sensitive context on disk, increasing exposure on stolen session keys, shared devices, or account takeover.

Vulnerable logic:

const skipImplicitExpiry = hasProviderOwnedSession(entry) && resetPolicy.configured !== true;
const entryFreshness = entry
  ? isSystemEvent || skipImplicitExpiry
    ? ({ fresh: true } satisfies SessionFreshness)
    : evaluateSessionFreshness({ updatedAt: entry.updatedAt, now, policy: resetPolicy })
  : undefined;

resetPolicy.configured is set based on whether any reset setting is present; when not configured, the default daily reset exists operationally but is not enforced for these sessions.

Recommendation

Do not disable the implicit daily expiry for provider-owned CLI sessions by default. Options:

1. Preserve CLI continuity while still rolling the gateway session (recommended): on daily reset boundaries, start a new gateway session and archive transcripts, but carry forward only the CLI binding.

2. Add a hard maximum age for provider-owned sessions (e.g., 24h or configurable) even when session.reset is not explicitly configured.

Example approach (preserve binding while resetting rest):

const cliBinding = provider ? getCliSessionBinding(entry, provider) : undefined;
const entryFreshness = entry
  ? isSystemEvent
    ? ({ fresh: true } satisfies SessionFreshness)
    : evaluateSessionFreshness({ updatedAt: entry.updatedAt, now, policy: resetPolicy })
  : undefined;

​// if stale daily but provider-owned, roll session but reattach cli binding to new entry
if (entry && cliBinding && entryFreshness?.dailyResetAt && entry.updatedAt < entryFreshness.dailyResetAt) {
  ​// proceed with rollover, but copy cliBinding into the new session entry
}

Also document and/or make this behavior an explicit config flag (opt-in) to avoid surprising data retention changes.

Description

The gateway now persists cliSessionBindings in the session entry patch during agent requests. This metadata includes provider session identifiers and account/profile linkage fields (e.g., authProfileId, mcpConfigHash, mcpResumeHash).

Because gateway session endpoints (e.g., sessions.reset) return the session entry object to connected clients, persisting these bindings increases the risk of information disclosure:

• cliSessionBindings is copied into the updated session entry on each agent refresh, ensuring it remains present in the session store.
• Gateway session RPC responses can include entry.cliSessionBindings (see sessions.reset test expectations), meaning this provider-owned metadata can be sent over the gateway API/WebSocket to any client that is authorized to call these endpoints.

Vulnerable change (persistence/enabling propagation):

cliSessionIds: entry?.cliSessionIds,
cliSessionBindings: entry?.cliSessionBindings,
claudeCliSessionId: entry?.claudeCliSessionId,

If the gateway is used in a multi-client or multi-tenant context (or if less-trusted clients can connect), this can leak identifiers that link a user/session to a specific provider account/profile and may aid session correlation or other abuse.

Recommendation

Treat cliSessionBindings as server-only metadata.

• Do not include cliSessionBindings in session entries that are returned to gateway clients.
• If persistence is needed for backend reuse, keep it in a separate server-side store/namespace or explicitly strip it from any RPC response payloads.

Example: strip before returning entry from session APIs:

function sanitizeSessionEntryForClient(entry: SessionEntry): SessionEntry {
  const { cliSessionBindings, ...rest } = entry;
  return rest;
}

Additionally:

• Ensure only trusted/internal clients can call endpoints that return full session entries.
• Consider encrypting or hashing provider identifiers if they must traverse client boundaries.

1. src/agents/cli-session.ts, line 155-165 (link)

   Unhandled downgrade path in MCP hash fallback

   The && change correctly lets a legacy stored binding (no mcpResumeHash) be validated via mcpConfigHash when the current client provides one, but it also silently opens a reverse path: a stored binding that does have mcpResumeHash is no longer checked against it when the current client omits mcpResumeHash — the code falls straight through to mcpConfigHash. If the MCP server composition changed between sessions (different mcpResumeHash, same mcpConfigHash), that stale session would still be reused. The test suite only covers the intended upgrade direction (stored = no hash, current = hash), not the downgrade direction (stored = hash, current = no hash).

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/agents/cli-session.ts
   Line: 155-165
   
   Comment:
   **Unhandled downgrade path in MCP hash fallback**
   
   The `&&` change correctly lets a legacy stored binding (no `mcpResumeHash`) be validated via `mcpConfigHash` when the current client provides one, but it also silently opens a reverse path: a stored binding that *does* have `mcpResumeHash` is no longer checked against it when the current client omits `mcpResumeHash` — the code falls straight through to `mcpConfigHash`. If the MCP server composition changed between sessions (different `mcpResumeHash`, same `mcpConfigHash`), that stale session would still be reused. The test suite only covers the intended upgrade direction (stored = no hash, current = hash), not the downgrade direction (stored = hash, current = no hash).
   
   How can I resolve this? If you propose a fix, please make it concise.