Best possible solution:

Retry the Codex review after fixing the execution failure.

Do we have a high-confidence way to reproduce the issue?

Unclear. The review failed before ClawSweeper could establish a reproduction path.

Is this the best way to solve the issue?

Unclear. Retry the review first so ClawSweeper can evaluate the actual issue and fix direction.

AGENTS.md: unclear because the file could not be read completely.

Codex review notes: model gpt-5.5, reasoning high; reviewed against b9933b2ec119.

Label justifications:

• rating: 🌊 off-meta tidepool: Overall readiness is 🌊 off-meta tidepool; proof is 🌊 off-meta tidepool and patch quality is 🌊 off-meta tidepool.

PR surface:

Source -7, Tests +91, Docs +1. Total +85 across 4 files.

What I checked:

• failure reason: codex execution failed.
• codex failure detail: Codex review failed for this PR with exit 1.
• codex stdout: Per-item Codex failure; continuing with the rest of the shard.

Likely related people:

• unknown: Codex failed before it could trace repository history. (role: review did not complete; confidence: low)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Description

The sessions_send tool accepts a sessionKey that may actually be a UUID sessionId. It resolves that sessionId to a canonical session key via sessions.resolve (with includeGlobal/includeUnknown when not sandbox-restricted), and then enforces visibility/A2A policy.

When the visibility/A2A check fails, the tool returns an error including sessionKey: displayKey, which is derived from the resolved canonical key. This allows a caller who is not allowed to send (e.g., tools.agentToAgent.enabled=false or tools.sessions.visibility not all) to probe sessionIds and learn the existence and canonical keys of otherwise-hidden sessions.

Impact:

• Confirms whether a given sessionId exists (enumeration)
• Leaks the canonical session key format (e.g., agent:main:subagent:worker) for sessions the caller cannot access
• Enables targeted follow-on attempts elsewhere that accept session keys, and reveals internal structure/agent names

Vulnerable code:

const access = visibilityGuard.check(resolvedKey);
if (!access.allowed) {
  return jsonResult({
    ...,
    error: access.error,
    sessionKey: displayKey, // leaks resolved key
  });
}

Recommendation

Do not reveal the resolved/canonical session key when the requester is not authorized.

Suggested changes:

• On denied access, return only the original identifier provided by the caller (or omit sessionKey entirely).
• Additionally, consider tightening sessionId resolution so it does not search includeGlobal/includeUnknown unless visibility actually permits those sessions.

Example fix:

const access = visibilityGuard.check(resolvedKey);
if (!access.allowed) {
  return jsonResult({
    runId: crypto.randomUUID(),
    status: access.status,
    error: access.error,
    ​// Avoid leaking resolved key; echo the caller input or omit.
    sessionKey: sessionKeyParam ?? labelParam ?? undefined,
  });
}

And/or gate the sessionId resolution flags based on effective visibility/A2A policy before calling sessions.resolve for sessionIds.