Greptile Summary

This is a docs-only PR that adds the resumeSessionId parameter (introduced in #41847) to the sessions_spawn interface documentation in docs/tools/acp-agents.md. The change is a focused 26-line addition: one new interface-detail bullet and a new "Resume an existing session" subsection containing a JSON example, use-case list, and notes on runtime requirements, supported agents, and error behaviour.

Key observations:

• The new content is accurate and consistent with the surrounding interface-detail style.
• The notes correctly document the runtime: "acp" requirement, the session/load agent support scope (Codex and Claude Code), and the no-silent-fallback error behaviour.
• The one gap is that the interaction between resumeSessionId and the thread/mode parameters is never addressed — the interface-detail section already warns that mode: "session" requires thread: true, but readers are left to guess whether those fields are applicable, ignored, or invalid when resumeSessionId is present. A single clarifying sentence in the notes would close this.

Confidence Score: 4/5

• Safe to merge — docs-only change with no runtime impact.
• The change is purely documentation. The new content is accurate, well-structured, and consistent with the rest of the file. The only gap is a missing clarification on the thread/mode interaction with resumeSessionId, which is a style improvement rather than a correctness issue.
• No files require special attention beyond the one style note on docs/tools/acp-agents.md.

_{Last reviewed commit: 8932dab}

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟠 Broken access control/IDOR: ACP session resumption via resumeSessionId without authorization binding

Description

The ACP spawn tool accepts a caller-supplied resumeSessionId and forwards it to the ACP runtime, which runs acpx sessions new --resume-session <id> to replay/load prior conversation history.

There is no authorization check that the supplied resumeSessionId belongs to (or was created by) the requesting user/session/account/tenant:

• Input: resumeSessionId is read directly from tool parameters (sessions_spawn) without validation beyond being a string.
• Sensitive action: it is passed into ACP initialization and then into the acpx CLI as --resume-session, which resumes an existing upstream ACP/Codex session and replays history.
• Missing authz: there is no check that the requester is allowed to access that upstream session ID.
• Impact: in a multi-user gateway environment (multiple chat users sharing the same gateway host/runtime), any user able to invoke sessions_spawn can potentially resume another user's ACP/Codex session by knowing/leaking its ID, gaining access to prior conversation contents (secrets, code, credentials) and continuing the session.

Additionally, ACP "agent session id" values are rendered into thread intro/details messages, increasing the chance that these IDs leak to other participants and effectively become bearer tokens for resumption:

• resolveAcpSessionIdentifierLinesFromIdentity formats agent session id: ... for display.

Vulnerable code (accepting and forwarding resumeSessionId):

const resumeSessionId = readStringParam(params, "resumeSessionId");
...
const result = await spawnAcpDirect({
  ...
  resumeSessionId,
  ...
});

Sink in the ACPX runtime (resume without any auth binding):

const resumeSessionId = asTrimmedString(input.resumeSessionId);
const ensureSubcommand = resumeSessionId
  ? ["sessions", "new", "--name", sessionName, "--resume-session", resumeSessionId]
  : ["sessions", "ensure", "--name", sessionName];

Example leakage surface (session identifier rendered to user-visible text):

if (agentSessionId) {
  lines.push(`agent session id: ${agentSessionId}`);
}

Recommendation

Bind resumption to an authenticated/authorized principal; do not treat resumeSessionId as a bearer token.

Concrete options:

1. Store and enforce ownership

• When an ACP session is created/resolved, persist a mapping of {agentSessionId/acpxSessionId -> ownerPrincipal} (principal could be accountId, requesterInternalKey, org/tenant id, etc.).
• On sessions_spawn with resumeSessionId, look up the mapping and reject if it does not match the requester.

2. Use scoped state directories

• Run ACP backends with a per-user/per-account state dir (separate ~/.codex/sessions equivalents) so one user cannot access another user’s session material on disk.

3. Reduce identifier leakage

• Do not emit full resumable session identifiers into shared thread intro text; gate it behind an owner-only policy or return it only in a private/admin surface.

Illustrative enforcement sketch:

​// Pseudocode inside spawnAcpDirect or acpManager.initializeSession wrapper
if (params.resumeSessionId) {
  const owner = await resumeRegistry.lookupOwner(params.resumeSessionId);
  if (!owner || owner.accountId !== ctx.agentAccountId) {
    return { status: "forbidden", error: "Not authorized to resume this session." };
  }
}

Analyzed PR: #42280 at commit 1a48586

_{Last updated on: 2026-03-10T16:17:43Z}

Merged without landpr because it's a simple doc change