Best possible solution:

Keep the shared visibility guard strict until the PR only marks aliases that resolve to the actual requester as current, adds denial coverage for non-main requesters targeting main aliases, and includes redacted live proof of the fixed workflow.

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

Yes for the patch defect: source inspection shows a requester such as agent:main:telegram:direct:123 receives currentSessionKeys containing main, and the PR checker then treats that target as current under self/tree. I did not run tests because this review is read-only.

Is this the best way to solve the issue?

No, this is a plausible layer but not the best fix as written. The safer fix should derive current aliases from the actual requester/semantic-current resolution only, not add configured main aliases for every requester.

Full review comments:

• [P1] Limit current aliases to the actual requester — src/agents/tools/sessions-access.ts:40-42
currentSessionKeys includes alias, mainKey, and literal main for every caller. For a non-main same-agent requester, main resolves to the main session but now passes isRequesterSession, so sessions_history, sessions_list, and sessions_send can bypass self/tree visibility; build this set only from keys that resolve to the requester and add denial tests for main aliases from non-main requesters.
  Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.92

AGENTS.md: found and applied where relevant.

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

Label justifications:

• P2: This is a normal-priority session visibility fix PR with a blocking security-boundary issue before merge, not an already-merged user-facing emergency.
• merge-risk: 🚨 security-boundary: The diff can make main-session aliases pass self/tree checks for non-main same-agent requesters in shared session tools.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body only lists test, format, and type commands; the external contributor should add redacted live output, logs, a terminal screenshot, or a recording/artifact showing the after-fix behavior, then update the PR body so ClawSweeper re-reviews automatically or a maintainer can comment @clawsweeper re-review.

PR surface:

Source +17, Tests +33. Total +50 across 6 files.

Security concerns:

• [high] Main aliases can bypass session visibility — src/agents/tools/sessions-access.ts:40
  The added alias set includes alias, mainKey, and main without checking whether they identify the requester; because the shared checker accepts any set member as the requester session before self/tree denials, non-main requesters can gain main-session visibility through list/history/send.
  Confidence: 0.91

What I checked:

• PR alias set admits global main aliases: At PR head, resolveSandboxedSessionToolContext builds currentSessionKeys from effectiveRequesterKey, requesterInternalKey, alias, mainKey, and literal main, so non-main requesters inherit configured main aliases as current-session keys. (src/agents/tools/sessions-access.ts:40, 8484484f3ef6)
• PR checker trusts every currentSessionKeys hit: At PR head, createSessionVisibilityRowChecker treats any key in currentSessionKeys as isRequesterSession before the self and tree denials run. (src/plugin-sdk/session-visibility.ts:306, 8484484f3ef6)
• Current main keeps self limited to requester/current: Current main only treats the exact requester key or literal current as the requester session in the shared visibility checker, so the PR is the source of the broader alias trust. (src/plugin-sdk/session-visibility.ts:303, f789081bae12)
• Resolution makes main aliases security-relevant: Current resolution maps input main to the configured alias, and display logic also labels either alias or mainKey as main, so adding both to currentSessionKeys affects real resolved targets. (src/agents/tools/sessions-resolution.ts:62, f789081bae12)
• Sibling status behavior blocks this access pattern: Current session_status tests explicitly block a non-main same-agent requester from accessing agent:main:main or bare main under tools.sessions.visibility=self, which is the boundary this PR would weaken for list/history/send. (src/agents/openclaw-tools.session-status.test.ts:1775, f789081bae12)
• Real behavior proof missing: The PR body lists Vitest, oxfmt, and tsgo commands only; no redacted live output, logs, recording, terminal screenshot, or linked artifact demonstrates the changed behavior after the patch. (8484484f3ef6)

Likely related people:

• @steipete: Introduced the split access/resolution helpers and shared session tool context used by this PR. (role: feature-history owner; confidence: high; commits: 1a03aad24649, 8a4f9f168bd5, 42d6e35cb45f; files: src/agents/tools/sessions-access.ts, src/agents/tools/sessions-resolution.ts, src/agents/tools/sessions-history-tool.ts)
• Robin Waslander: Added recent session_status visibility hardening and tests that preserve the non-main requester boundary for main aliases. (role: security-boundary hardening contributor; confidence: medium; commits: 4d369a3400dc; files: src/agents/tools/session-status-tool.ts, src/agents/openclaw-tools.session-status.test.ts)
• @vincentkoc: Recent history shows multiple agent/status/access-boundary changes near the same session visibility surface. (role: adjacent area contributor; confidence: medium; commits: 11318ef9b949, 340c99d65733, 7cd0ff2d888f; files: src/agents/tools/session-status-tool.ts, src/plugin-sdk/session-visibility.ts)
• NVIDIAN: Current shallow blame for the shared session visibility/access files points at this author, though the commit summary is broad and the ownership signal is weaker than the focused history above. (role: recent current-line contributor; confidence: low; commits: eb417bc672e6; files: src/agents/tools/sessions-access.ts, src/plugin-sdk/session-visibility.ts, src/agents/tools/sessions-resolution.ts)

• 🦀 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.