feat(types): add targetClientId to HostBashRequest and PendingInteraction#29309
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| /** When set, the host_bash request should be routed to this specific client. */ | ||
| targetClientId?: string; |
There was a problem hiding this comment.
🟡 registerPendingInteraction does not propagate targetClientId from HostBashRequest to PendingInteraction
The PR adds targetClientId to both HostBashRequest (message type) and PendingInteraction (tracker type), but the bridge code in registerPendingInteraction at assistant/src/runtime/assistant-event-hub.ts:584-588 constructs the PendingInteraction without copying msg.targetClientId. When a host_bash_request message with targetClientId set is broadcast, the corresponding pending interaction will always have targetClientId: undefined, making the field on PendingInteraction permanently ineffective.
Bridge code that omits the field
} else if (msg.type === "host_bash_request") {
pendingInteractions.register(msg.requestId, {
conversationId,
kind: "host_bash",
// targetClientId is missing here
});Prompt for agents
The registerPendingInteraction function in assistant/src/runtime/assistant-event-hub.ts (around line 584-588) needs to propagate targetClientId from the message to the pending interaction. The host_bash_request branch currently constructs the PendingInteraction with only conversationId and kind, but should also include targetClientId: msg.targetClientId (or equivalent). This is the bridge between the HostBashRequest message type and the PendingInteraction tracker type -- both types now have the targetClientId field, but the bridge code doesn't copy it across.
Was this helpful? React with 👍 or 👎 to provide feedback.
| /** When set, route this request only to the client with this ID. */ | ||
| targetClientId?: string; |
There was a problem hiding this comment.
🚩 Swift client HostBashRequest struct does not include targetClientId
The Swift HostBashRequest struct at clients/shared/Network/MessageTypes.swift:1532-1551 has explicit CodingKeys and does not include a targetClientId property. When the daemon sends a host_bash_request with targetClientId set, the Swift client will silently ignore it during JSON decoding (since Decodable skips unknown keys by default). If the client needs to act on this field (e.g., to check whether it's the intended target before executing), the struct and its CodingKeys will need updating in a follow-up PR.
Was this helpful? React with 👍 or 👎 to provide feedback.
| /** When set, route this request only to the client with this ID. */ | ||
| targetClientId?: string; |
There was a problem hiding this comment.
🚩 broadcastMessage routing does not use targetClientId for client-specific delivery
The broadcastMessage function at assistant/src/runtime/assistant-event-hub.ts:473-528 routes host-proxy messages by targetCapability (sending to all subscribers with host_bash capability), but has no mechanism to restrict delivery to a single client by ID. Even if targetClientId is set on the HostBashRequest, the message will fan out to every subscriber with the host_bash capability. The assistantEventHub.publish method (assistant/src/runtime/assistant-event-hub.ts:255) accepts only { targetCapability } in its options — there is no targetClientId filtering. This is expected for a preparatory type change, but the actual routing logic will need to be added for the feature to work.
Was this helpful? React with 👍 or 👎 to provide feedback.
credence-the-bot
Bot
merged commit 955bf7b
into
Credence/targeted-host-proxy
credence-the-bot
Bot
deleted the
targeted-host-proxy/pr-2-targetclientid-types
branch
Summary
targetClientId?: stringtoHostBashRequestmessage typetargetClientId?: stringtoPendingInteractioninterfacePart of plan: targeted-host-proxy.md (PR 2 of 8)