Greptile Summary

This PR removes the strict mutual-exclusivity check between sessionKey and label in sessions_send, replacing it with a simple preference: when both parameters are supplied, sessionKey wins and label is silently ignored. The motivation is solid — LLMs (GPT, Kimi, DeepSeek) reliably populate all optional parameters, causing spurious tool-call failures for agent-to-agent communication.

Key observations:

• The change is minimal (7 lines removed, 4 added) and only affects the error-guard path; all existing single-parameter flows are unaffected.
• The existing fallback if (!sessionKey && labelParam) already naturally handles the "label only" path, so the preference logic is implicit and correct.
• agentId (used only in label resolution) is also silently ignored when sessionKey takes precedence, which is the right behavior.
• No new error paths are introduced; the downstream if (!sessionKey) guard at line 149 still catches the case where neither parameter is provided.

Confidence Score: 5/5

• This PR is safe to merge — it is a strictly additive, backward-compatible relaxation of an overly strict validation.
• The diff is tiny (one removed guard block, one comment), the logic is straightforward, no existing behavior changes, and the downstream safety net (if (!sessionKey)) remains intact. All three original call patterns (key-only, label-only, both) are handled correctly.
• No files require special attention.

_{Last reviewed commit: 5e5f3b8}

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

Codex automated review: keeping this open.

Keep open. Current main at a253660 still rejects sessions_send calls that include both sessionKey and label, so this PR's intended behavior is not implemented. The PR remains a plausible implementation candidate for the sessions_send portion of #41199, though it should gain a focused regression test or be superseded by one of the duplicate PRs that already includes coverage.

Best possible solution:

Keep this PR open as a valid implementation candidate until maintainers choose and merge one canonical sessions_send precedence fix. The best path is to land a narrow change that removes the dual-selector rejection, proves sessionKey wins when both selectors are present, preserves label-only behavior and missing-target errors, and then close duplicate PRs plus the sessions_send portion of #41199.

What I checked:

• Current main still rejects dual selectors: sessions_send reads sessionKey, label, and agentId, then returns Provide either sessionKey or label (not both). when both target selectors are present. (src/agents/tools/sessions-send-tool.ts:105, a25366038503)
• Existing control flow supports the proposed precedence once the guard is removed: After the guard, let sessionKey = sessionKeyParam and label resolution only runs under if (!sessionKey && labelParam), so the PR's one-file change would naturally prefer sessionKey while preserving label-only lookup. (src/agents/tools/sessions-send-tool.ts:116, a25366038503)
• Current tests do not cover the mixed selector path: Targeted search found only missing-target and label-only coverage, not a regression test for providing both sessionKey and label. (src/agents/tools/sessions.test.ts:612, a25366038503)
• Latest release still has the same guard: Tag v2026.4.26 points at the latest release and its sessions_send implementation still contains the dual-selector rejection. (src/agents/tools/sessions-send-tool.ts:105, be8c24633aaa)
• Security review of PR surface: The provided PR diff changes only src/agents/tools/sessions-send-tool.ts by removing the strict target-selector guard and adding explanatory comments. It does not touch workflows, dependencies, lockfiles, install/build/release scripts, secrets handling, package metadata, generated/vendor files, or downloaded code execution paths. (src/agents/tools/sessions-send-tool.ts:108, 5e5f3b826a02)
• Related work is open, not merged: The provided GitHub context shows Agent-to-Agent Communication Tools Have Parameter Conflicts #41199 is still open and duplicate implementation candidates fix: prefer sessionKey over label in sessions_send #39551, fix(sessions_send): prefer sessionKey over label when both are present (AI-assisted) #56203, and fix(agents): prefer sessionKey in sessions_send #59324 are also open. No canonical fix has merged, so this PR is not obsolete on current main.

Remaining risk / open question:

• This PR does not add a focused regression test for the sessionKey plus label path; a duplicate PR with equivalent behavior and coverage may be the better merge target.
• The behavior intentionally becomes more permissive when callers pass mismatched sessionKey and label; maintainers should lock in and document that sessionKey is authoritative, while relying on the existing downstream visibility and A2A policy checks.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against a25366038503.

Thanks @he-yufeng. I’m closing this as superseded by #39551 because both PRs target the same sessions_send mixed sessionKey/label rejection, and #39551 is now the maintained canonical contributor branch for the sessionKey-first fix.

Clownfish is keeping the canonical review path on #39551 so validation, follow-up, and contributor credit stay in one place. Credit for this narrow fix remains in this source PR. If this branch covers a distinct behavior that still reproduces after #39551 lands, please reply and we can reopen or split it back out.