Skip to content

FIRE-1896 | gemini-cli agent-ids support - #35

Draft
yuval-qf wants to merge 1 commit into
mainfrom
feature/gemini-subagent-attribution
Draft

FIRE-1896 | gemini-cli agent-ids support#35
yuval-qf wants to merge 1 commit into
mainfrom
feature/gemini-subagent-attribution

Conversation

@yuval-qf

Copy link
Copy Markdown
Contributor

…nt-id

A Gemini subagent's own hook events are shape-identical to the main agent's: createBaseInput emits only session_id / transcript_path / cwd / hook_event_name / timestamp, and none of them names the delegation that is running. Its tool calls therefore persisted with no attribution at all, while only the delegation report carried a name.

Gemini's own transcript records do name it, and the rule is bookkeeping rather than timing: a delegation appears in the per-session subagent directory when it STARTS and in the parent transcript when it ENDS, so started-minus-finished is what is running. The remaining UUID is the subagent's session id, which is also the vendor agentId upstream stamps on the completed invoke_agent record, so it is a real per-instance id rather than a slug two concurrent runs would share.

No timestamp of any kind is read or compared. An earlier design selected the live delegation by mtime, which would have made correctness depend on filesystem timestamp resolution.

The POSTed body stays byte-for-byte the bytes read from stdin. The payload is parsed into a local for inspection only; everything derived travels as a header, and the tests assert body identity against the raw inbound bytes on every attribution case.

Sends only the id. The agent name is already inside the relayed bytes on the one event that has one, and the backend reads it from there.

Every failure path yields no header, never a wrong id: concurrent delegations, a missing directory, an unreadable or oversized parent, a delegation recorded without an agentId (matched by its prompt instead), or an id that would not be header-safe.

…nt-id

A Gemini subagent's own hook events are shape-identical to the main
agent's: createBaseInput emits only session_id / transcript_path / cwd /
hook_event_name / timestamp, and none of them names the delegation that
is running. Its tool calls therefore persisted with no attribution at
all, while only the delegation report carried a name.

Gemini's own transcript records do name it, and the rule is bookkeeping
rather than timing: a delegation appears in the per-session subagent
directory when it STARTS and in the parent transcript when it ENDS, so
started-minus-finished is what is running. The remaining UUID is the
subagent's session id, which is also the vendor agentId upstream stamps
on the completed invoke_agent record, so it is a real per-instance id
rather than a slug two concurrent runs would share.

No timestamp of any kind is read or compared. An earlier design selected
the live delegation by mtime, which would have made correctness depend on
filesystem timestamp resolution.

The POSTed body stays byte-for-byte the bytes read from stdin. The
payload is parsed into a local for inspection only; everything derived
travels as a header, and the tests assert body identity against the raw
inbound bytes on every attribution case.

Sends only the id. The agent name is already inside the relayed bytes on
the one event that has one, and the backend reads it from there.

Every failure path yields no header, never a wrong id: concurrent
delegations, a missing directory, an unreadable or oversized parent, a
delegation recorded without an agentId (matched by its prompt instead),
or an id that would not be header-safe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Aug 13, 2026

Copy link
Copy Markdown

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: fbfc5017-2e2d-461c-816b-8f5e9d0f30ef

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant