← Back to PRs

#6430: feat(protocol): include agent identity in hello-ok handshake response

by astoreyai open 2026-02-01 17:09 View on GitHub →
app: web-ui gateway
Resolves #6411 ## Summary Adds an optional `identity` field to the `hello-ok` handshake response payload containing the active agent's name and avatar. ## Motivation Node apps (mobile clients, CLI tools) that connect to a gateway currently have no way to discover the active agent's identity at connect time. This forces hardcoding or extra RPC calls. ## Changes - `src/gateway/server/ws-connection/message-handler.ts`: Resolve and include agent identity in hello-ok - `src/gateway/protocol/schema/frames.ts`: Add optional identity field to hello-ok schema ## Details Uses the existing `resolveAssistantIdentity()` which merges identity from: 1. `ui.assistant` config 2. Per-agent `identity` config (`agents.list[].identity`) 3. `IDENTITY.md` in agent workspace 4. Default fallback ("Assistant") Only non-sensitive fields are included (`name`, `avatar`). Backwards compatible — clients that don't need the field can ignore it. ## Testing The identity resolution is already well-tested via `resolveAssistantIdentity()`. The addition is a simple field inclusion in the response object. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR extends the gateway handshake (`hello-ok`) payload to optionally include an `identity` object (`name`, optional `avatar`) so connecting clients can discover the active agent identity without an extra RPC. The protocol schema is updated accordingly, and the websocket connect handler resolves identity during the handshake response build. Overall the change is small and backwards-compatible (new optional field), but the current implementation re-loads config during the handshake and swallows identity-resolution errors silently, which can make the response inconsistent and harder to debug if identity unexpectedly goes missing. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge with low risk, but has minor implementation concerns around config consistency and diagnosability. - Schema change is additive (optional field) and the handshake payload addition is straightforward. Main risks are redundant `loadConfig()` on the handshake hot path and the silent catch masking unexpected failures, which could lead to hard-to-debug missing identity rather than breaking functionality. - src/gateway/server/ws-connection/message-handler.ts <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->

Most Similar PRs