Feature request: Support resumable tool results (submitToolOutputs / long-lived human-in-the-loop tools)

[mindtricksdev]

We’re building an MCP-style UI flow where a tool needs to request user input from a frontend and resume later (human-in-the-loop).

Today, tools must return immediately. There is no supported way to:
pause a tool execution
wait for user input (minutes later)
and then submit the tool result back into the same session.

We tried holding an async Promise open (e.g. 5–10 minutes), but the session times out / disconnects.
It would be very helpful to support a resumable pattern similar to:

session.submitToolOutputs({
  toolName: "renderUI",
  requestId,
  output: userData
});

or an equivalent API to resume a pending tool call.
This would enable:

• MCP-style UI tools
• human approval flows
• long-running external workflows
• durable agent state across frontend interactions

Is this pattern on the roadmap, or is there a recommended way to implement human-in-the-loop tools today?

At the moment, I rely on prompt engineering so the assistant finishes with a renderUI tool call, then I capture the UI input and send it back as a new user message. This works, but it’s suboptimal because it introduces an extra round-trip rather than continuing the original tool execution.

Thanks!

[github-actions]

Thanks for opening this feature request, @mindtricksdev!

This is a well-articulated enhancement request for resumable tool execution patterns that would support human-in-the-loop workflows. I've labeled this as an enhancement.

The use case you describe (long-lived tools awaiting user input, MCP-style UI flows, human approval) is clear, and you've provided both the current workaround and the desired API pattern (submitToolOutputs).

The maintainers will review this and provide feedback on feasibility and roadmap timing.

AI generated by Issue Triage Agent

[saikir1994]

Hi
I am looking for a similar function too.
OnPreToolUse - ask would trigger OnPermissionRequest. This should mean that a user can take infinite amount of time to come back and take action. how is this handled?
Or should the interactive response be in a short span?

From what I understand, the process in background is live and waiting on the handler and not moving ahead. A more easier approach would be to let the caller suspend and resume at a later point?

[Keesan12]

Resumable tool results get much easier to govern if the pause itself is first-class.

I'd model it less as hold a Promise open and more as awaiting_external_input with a resumable receipt: tool call id, requested fields, who is allowed to answer, expiry, and what stop reason to emit if nobody resumes it.

That keeps human-in-the-loop flows auditable and makes timeout and budget policy explicit instead of implicit transport behavior.

[stephentoub]

Thanks. This has been addressed. The runtime persists pending permission and tool call information and enables their results to be supplied after resumption. And the SDK supports providing tools that do not have callbacks, in which case you can be fully in control by listening for permission/tool call events, shutting down, and then later resuming and calling the various methods to supply the results. For example, https://github.com/github/copilot-sdk/blob/main/dotnet/samples/ManualToolResume.cs.

[Keesan12]

This is a helpful direction. The part I’d still want to see made explicit in the resume contract is the policy receipt around the pause itself: expiry, who is allowed to answer, and what machine-readable stop state gets emitted if the tool call never resumes.

If those fields are already carried in the persisted pending-permission / pending-tool state, that closes most of the auditability gap for long-lived human-in-the-loop tools.