Skip to content

feat(types): add targetClientId to HostBashRequest and PendingInteraction #29309

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
credence-the-bot merged 1 commit into from
May 3, 2026
Merged

feat(types): add targetClientId to HostBashRequest and PendingInteraction #29309

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions assistant/src/daemon/message-types/host-bash.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,8 @@ export interface HostBashRequest {
timeout_seconds?: number;
/** Extra environment variables to inject into the subprocess (e.g. VELLUM_UNTRUSTED_SHELL). */
env?: Record<string, string>;
/** When set, route this request only to the client with this ID. */
targetClientId?: string;
Comment on lines +16 to +17
Copy link
Copy Markdown
Contributor

@devin-ai-integration devin-ai-integration Bot May 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚩 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.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment on lines +16 to +17
Copy link
Copy Markdown
Contributor

@devin-ai-integration devin-ai-integration Bot May 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚩 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.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

}

export interface HostBashCancelRequest {
Expand Down
2 changes: 2 additions & 0 deletions assistant/src/runtime/pending-interactions.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,6 +51,8 @@ export interface PendingInteraction {
confirmationDetails?: ConfirmationDetails;
/** For ACP permissions: resolves directly without a Conversation object. */
directResolve?: (decision: UserDecision) => void;
/** When set, the host_bash request should be routed to this specific client. */
targetClientId?: string;
Comment on lines +54 to +55
Copy link
Copy Markdown
Contributor

@devin-ai-integration devin-ai-integration Bot May 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 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.
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

}

const pending = new Map<string, PendingInteraction>();
Expand Down
Loading