Agent-Native 0.187: Where Should Tool Approvals Resume?

An embedded app's tool approval should resume the app chat that owns the paused run. If permission keeps being requested, trace the continuation before changing the permission policy. A message reaching the surrounding host chat does not establish that the waiting action received its grant.

Consider a hypothetical app that accepts the approval click and then asks again. The useful diagnosis begins with where the approval information went, not with another prompt telling the model that you already approved.

Builder.io's Agent-Native 0.187 release says browser approval continuations stay in the app chat that owns the paused run inside a Builder frame or an MCP App embed. The developer's job is to trace that continuation through the actual integration, preserve its approval information and verify the receiving run. This is a routing and handoff question, not a reason to disable tool approval.

The core release was published on September 24, 2026, according to the original GitHub release record. The approval-routing commit shows the relevant client changes and regression tests. This article is a source-based integration review. The proposed checks have not been performed in a live app.

Key takeaways

• A tool approval must reach the paused run's continuation, not merely produce reassuring text in another chat.
• Builder.io's fix treats the named embedded contexts differently from ordinary code requests and ordinary host-chat messages.
• Inspect the bridge, send options and receiving run together. A successful browser send does not by itself prove the tool completed.
• Test both approval continuations and neighboring message types before adopting the routing change in your own integration.

Identify the chat that owns the paused run

Begin with ownership, rather than with the most prominent chat window. An embedded app can display its own agent beside a host chat. Similar placement does not mean the two chats carry the same run or approval information. The useful route is the one connected to the paused action.

The original commit describes an approval continuation inside a Builder frame being sent toward Builder's chat. That path did not have a field for the app's approval keys, and the app's durable grant lived elsewhere. The commit also describes MCP host paths that forwarded message text without the approval information needed by the app's run.

For your integration review, draw the specific surfaces involved. Label the app chat, the surrounding host chat and any code-editing frame. Then identify which run is waiting for approval and which component created the pending action. These are questions to answer from the deployed application's implementation, not assumptions supplied by the release note.

A hypothetical embedded reporting app makes the distinction concrete. Its own agent pauses before writing a draft report. A host assistant outside the app can explain the report, but that does not establish that it owns the paused write. Sending the words approved into the host conversation may look successful while leaving the app's run unchanged.

Ownership should remain intelligible to the person reviewing the integration later. Record the run or thread identity through the inspection points your host exposes. If a bridge strips those connections, an attractive approval control can become difficult to diagnose. The issue is not how confidently the interface confirms the click. It is whether the correct run receives the continuation.

View image detail

The paused run has an owner. Identify the app’s waiting action. Distinguish its chat from the outer host. Approval must reach the correct run.

Actual size

Choose Actual size to read the graphic closely.

Trace the approval through the browser message

The release says approval information travels through the browser's agent-chat submit path into the run configuration. The original commit adds handling for the approvedToolCalls field in that transport. It also carries the information through the multi-tab chat layer into the send options used by the app chat.

Trace each handoff: what the control submits, what the bridge parses, what a pending send retains, and what reaches the receiving chat. A field can exist in the first object and still disappear when a later adapter reconstructs the request from a smaller set of values.

The patch is useful because it shows that failure mode in ordinary application code. It changes the way send options are assembled rather than assuming a transport automatically preserves a newly added field. For a custom host, the practical lesson is to inspect every adapter that selects fields, not simply the interface closest to the approval button.

Use the field name from the inspected source when examining this version. Do not replace that inspection with an invented generic token interface or a claim that every host supports the same method. A changed wrapper, an older installed package or a separate submission path can make the deployed route differ from the release's implementation.

A helpful proposed trace records whether the approval information is present at each boundary and whether it targets the same pending action. Sensitive grant values do not need to appear in screenshots or a public bug report. The engineer can retain protected evidence and summarize presence, identity matching and destination without publishing the keys themselves.

View image detail

Follow every approval handoff. Inspect the control and browser bridge. Check retained fields in the pending send. Then inspect the receiving run configuration.

Actual size

Choose Actual size to read the graphic closely.

Preserve the difference between a continuation and a new prompt

A paused tool call needs a continuation of its existing work. Creating another visible prompt with the text approved can be a different event. The 0.187 release describes the approval resume as a hidden protocol continuation, and the original changes carry the option that keeps it out of ordinary visible message history.

Hidden in this context concerns how the message is represented in the chat. It should not be read as a promise that the action is unlogged, unreviewable or outside the application's permission system. The developer still needs to establish how the receiving run processes it and what evidence the host exposes for an audit.

For a proposed integration check, compare the pending action before the click with the continuation received afterward. Confirm that you are resuming that action rather than starting a new task that happens to mention approval. A second ordinary message can give the model ambiguous instructions while leaving the original pending grant unresolved.

The source also makes the handoff more specific than a UI convenience. Its type comments say the server consumes a matching durable grant. Treat that as documented intent in the inspected code, not as an independent security evaluation of every server configuration. A client carrying a field does not prove the full authorization path works in the deployment you maintain.

Keep the user-facing explanation simple. The person making a decision needs to know what action is awaiting approval and whether that action resumed. They do not need transport field names on every button. The technical trace belongs in the implementation and protected review evidence; the product should make the actual action and its state understandable.

View image detail

A continuation is not a new prompt. Resume the existing paused action. Ordinary chat text can follow another route. Neither send proves a completed tool result.

Actual size

Choose Actual size to read the graphic closely.

Review the Builder-frame route separately

Inside a Builder frame, the change keeps approval continuations in the embedded app's chat. The commit explains that an ordinary code-typed send could previously take the route toward Builder's chat even though that route lacked the app's approval information. The patch changes the routing decision for the approval case.

That is a reason to test the exception carefully, not to redirect every code request locally. The same source includes a neighboring case in which a code approval outside the Builder frame continues along the code-frame route. A custom integration should preserve the distinction that its actual context requires.

A proposed review can start by recording whether the app is in the named frame context and whether the message carries approval information. Inspect the selected target, then compare it with the target for an ordinary request to edit code. Those two requests can have similar visible wording while requiring different destinations.

In a hypothetical app, the user might ask the surrounding development assistant to change a report component. That is different from approving a tool call already paused in the report app's own agent. The first is a new code request. The second continues an existing run. A single routing rule based only on the word code would miss the relevant difference.

Write the acceptance condition around that difference. For the approval case, the app's receiving chat should get the continuation for the correct paused action. For the ordinary code case, the host should retain its intended code-editing route. This is a proposed test contract derived from the patch's distinction, not a claim that a particular app has already passed it.

View image detail

Test the Builder-frame exception. App approval returns to its own run. A code request can need a different route. Check both cases in the actual integration.

Actual size

Choose Actual size to read the graphic closely.

Check both MCP App embed paths

The original change distinguishes a chat-bridge MCP App embed from a direct embed. In the described host transports, a surrounding host chat could receive text while the approval information did not reach the app's paused run. The patch keeps the approval continuation in the app chat for both named embed situations.

A developer reviewing an integration needs to know which route it actually uses. Do not infer that from an interface looking embedded. Inspect the application's existing bridge and embed detection, then trace the message target. The same visual layout can hide a different transport configuration.

The commit's regression tests also cover an ordinary MCP App message without approval keys. That message still follows the host-message path in the tested case. This matters because a fix for one continuation should not quietly break ordinary conversation with the host. Positive and neighboring negative cases belong together in a routing review.

For a proposed test matrix, separate the bridge embed, direct embed and ordinary non-approval message. In each row, name the starting context, the message's purpose and the expected receiver based on the inspected implementation. Leave the observed result empty until the corresponding check runs. A matrix full of expected paths is a plan, not evidence of successful integration.

An outer host receiving the words approved should not be your success condition for the embedded action. That shows only the text destination. The useful success condition is a trace connecting the user's approval to the waiting app run, followed by whatever receiving evidence that deployment provides. If you cannot inspect the receiving side, keep that part of the result unresolved.

View image detail

Separate the MCP message cases. Inspect the bridge and direct embed. Keep ordinary host messages distinct. Leave observed results empty until checked.

Actual size

Choose Actual size to read the graphic closely.

Keep message validation and permission validation distinct

The parser in the inspected commit accepts non-empty string entries for approval information, preserves their values and limits the array. Those are transport-shape checks. They do not independently establish that the requester may approve an action or that the supplied value matches a valid server-side grant.

This distinction prevents a tempting shortcut during debugging. If the model keeps asking for approval, removing validation or adding a broad allow rule might make the repeated prompt disappear. It would also change the authority boundary you were trying to preserve. Investigate delivery and grant matching before changing what the action is allowed to do.

Inspect your existing authorization layer separately from the browser message. Determine how the run, actor and pending action are matched in the actual implementation, and which evidence can show that decision. The 0.187 client patch alone is not a complete description of every deployment's authorization model, so do not treat its parser as the entire security contract.

Use malformed and mismatched inputs only in a controlled development environment you are authorized to test. A proposed regression suite should verify that invalid transport shapes do not become ordinary valid approvals and that a receiving path does not grant unrelated authority. Get the expected denial behavior from the server's supported contract. Do not invent a response code for the test.

For a nontechnical stakeholder, explain the two checks in plain terms: did the approval reach the correct action, and was it valid for that action? Solving the first does not justify skipping the second. The Rise discussion of expanding agent authority develops that broader review decision without treating a successful interface click as blanket permission.

View image detail

Transport shape is not authorization. A parser can accept a valid field shape. The server still must match the actual grant. Do not fix routing by widening permission.

Actual size

Choose Actual size to read the graphic closely.

Read the repository tests without claiming a live result

The original commit includes tests for browser payload parsing, forwarding through the multi-tab chat layer and placement in the run configuration. It also includes routing cases for the named frame and embed situations. These tests explain what the maintainers intended to preserve when they changed the client code.

Reading those tests is useful evidence for an integration review. It is not the same as running them, and running them would not by itself prove that your deployed app uses the same package, wrappers and server configuration. Keep the evidence levels separate when communicating the change to someone deciding whether to rely on it.

A proposed review record can have three fields: the repository case inspected, the corresponding path in your integration and the observed local result. Fill the first from the actual source. Fill the second after inspecting your application. Fill the third only after a controlled check. Missing observations should remain empty instead of becoming assumed passes.

The patch also includes a local confirmation case and a neighboring unsupported-target case. A developer should read confirmation as a transport acknowledgment within the documented path. It does not establish that a tool wrote a correct report, sent a valid message or completed the business task the user cares about.

Those separate conclusions make the review useful to operations. If a continuation reached the correct run but the tool later failed, the routing fix may still be functioning while the task remains unfinished. If the browser send was acknowledged but the receiving run cannot be identified, delivery remains uncertain. A single green status for all of those stages would conceal the evidence needed to diagnose the difference.

View image detail

Three records, three kinds of evidence. Read the repository’s intended case. Identify the deployed integration path. Record its actual local result separately.

Actual size

Choose Actual size to read the graphic closely.

Make repeated approval prompts diagnosable

A repeated permission request is a symptom, not a complete diagnosis. It could reflect a continuation that lost its approval information, a message sent to the wrong chat, a mismatch with the pending action or another behavior outside this client patch's scope. Start with the evidence you can inspect before proposing a fix.

In the hypothetical reporting app, record the action that paused and the approval event that followed. Then inspect whether the continuation reached the app's own chat and whether the run configuration retained the expected information. If those steps are visible and correct, continue into the receiving server's supported diagnostics rather than changing the host-message route again.

If the information disappears at a bridge, focus the repair on that handoff. If the message goes to a surrounding chat, compare the deployed routing decision with the named context in the original patch. If you cannot observe either boundary, add a protected inspection point in the application's normal development process before making a confident diagnosis.

Keep debug output proportionate. Approval values and private task details should not be copied into a public issue just to demonstrate that a field existed. An engineer can provide the relevant package version, context, field-presence result and sanitized routing evidence while preserving sensitive information in the authorized environment.

The resulting handoff should distinguish what was found from what is proposed. For example, a trace may establish that a bridge removed a field. Updating the adapter is then a concrete repair to evaluate. Without that trace, the same update is still a hypothesis. Clear evidence keeps a small routing bug from turning into a broad and unnecessary change to the permission system.

View image detail

Trace the symptom before changing policy. Check field presence through the bridge. Check the selected target and waiting run. Keep unresolved findings visible.

Actual size

Choose Actual size to read the graphic closely.

Set an acceptance boundary before shipping the integration

The acceptance decision should name the deployed version, the embed context and the behavior being verified. For this historical release, the immediate question is whether the app's approval continuation reaches the correct paused run while ordinary message routes retain their intended behavior. That is a narrower and more testable promise than saying approvals work everywhere.

Choose a disposable tool action that makes its receipt visible without affecting real client work. Confirm the user's decision, the continuation's destination and the receiving run's next state through the inspection points your application supports. If the tool executes, inspect its result separately. Do not label the workflow complete solely because the approval prompt stopped appearing.

Include the neighboring routes from the earlier review. A fix can solve an embedded approval case while accidentally redirecting an ordinary host message or a code-editing request. Preserve the distinction in the regression plan so a later wrapper change can be checked against the same intent.

For a connected agent product, the human decision needs a route to the action it actually approves. Put that contract around your approval handoff before you expand the agent's authority. When the route is clear, the application can explain which action resumed and reserve the human's attention for the decision that actually required it.

If a tool starts and its response is later interrupted, the next question changes from approval delivery to destination evidence. The companion guide to interrupted-write recovery explains that operator decision. Resuming the right run does not itself establish whether a consequential write succeeded.