Use a session handoff when a deployed Modal Function runs the complete screenshot, model, and action loop. The owner process keeps lifecycle ownership of the desktop.
Understand the ownership pattern
- Your application creates the desktop.
- The owner calls
session_handle().
- The owner passes the handle to a deployed Modal Function.
- The Function enters one
borrow_async() context for the complete trajectory.
- The Function detaches when the borrow ends.
- The owner terminates the desktop after the Function reaches a terminal result.
The handle contains routing identity. It is not a bearer credential. Do not log or publish it.
Define the deployed Function
Replace application_model_call() with your application code. Use an async provider client so the Function event loop remains available.
Set the same explicit region on the desktop configuration and the Function. The borrow checks function_region against the requested desktop region.
Deploy the Function
The deployed Function image must include modal-computer-use[modal]. The Function must have access to the Modal environment that owns the Sandbox.
Invoke the Function from the owner
Use one new run_id for each trajectory. Do not reuse a durably sealed run ID.
Keep one trajectory per desktop
The borrow takes an exclusive daemon trajectory lease. Concurrent work must use separate desktop handles.
The Function leaves the desktop running when the borrow ends. Only the original owner terminates it.
A cancelled Function invocation does not reverse desktop effects that already occurred. Your application must reconcile an ambiguous result before it starts a new trajectory.
Use the session handoff example when a Modal Function needs one complete stateful trajectory. It shows dispatch, cancellation, and observation after result loss. The owner must reconcile an ambiguous outcome before it starts another trajectory.