You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you read the docs? Yes, including the ComputerTool documentation.
Have you searched for related issues? Yes. I searched open and closed issues and pull requests for ComputerTool, ComputerProvider, per-run computer lifecycle, concurrent runs, and computer serialization. I found the original per-run lifecycle change in fix: Enable creating/disposing Computer per agent run #2191, but no report covering this concurrent serialization race.
Describe the bug
When two runs concurrently reuse an Agent containing the same ComputerTool backed by a ComputerProvider, the resolved Computer instances are cached per RunContextWrapper, but they are also written to the shared ComputerTool.computer field.
Reusing one configured Agent across concurrent application requests is a normal server pattern. PR #2191 introduced per-run computer creation and disposal specifically so provider-backed tools would not require rebuilding the agent for each request.
The preview-compatible Responses serializer reads that shared field to obtain environment and display dimensions. As a result, one run can serialize another run's computer configuration. If the first run completes and disposes its computer before the second run serializes, disposal restores the shared field to the provider and the second run fails with:
UserError: Computer tool is not initialized for serialization.
The GA computer payload does not require these dimensions, so the observed serialization failure is specific to preview-compatible payloads. However, the provider lifecycle is documented and implemented as per-run state, so concurrent runs should not share mutable resolved-computer state.
Debug information
Agents SDK version: v0.18.2 and main at 7369b73c
Python version: Python 3.13.13
Repro steps
From a repository checkout, save the following as repro_computer_concurrency.py and run it with uv run python repro_computer_concurrency.py. It uses a local fake model and makes no API request:
run A: done
run B failed: UserError Computer tool is not initialized for serialization. ...
serialized widths: [1002]
disposed widths: [1001, 1002]
Run A serializes run B's width. When run A then performs cleanup, run B sees the provider instead of its resolved computer and fails during serialization.
Expected behavior
Each run should pass its own resolved Computer instance to model serialization and tool execution. Concurrent runs that reuse the same Agent and ComputerTool should serialize their own dimensions, complete independently, and dispose exactly their own provider-created computer once.
Please read this first
ComputerTooldocumentation.ComputerTool,ComputerProvider, per-run computer lifecycle, concurrent runs, and computer serialization. I found the original per-run lifecycle change in fix: Enable creating/disposing Computer per agent run #2191, but no report covering this concurrent serialization race.Describe the bug
When two runs concurrently reuse an
Agentcontaining the sameComputerToolbacked by aComputerProvider, the resolvedComputerinstances are cached perRunContextWrapper, but they are also written to the sharedComputerTool.computerfield.Reusing one configured
Agentacross concurrent application requests is a normal server pattern. PR #2191 introduced per-run computer creation and disposal specifically so provider-backed tools would not require rebuilding the agent for each request.The preview-compatible Responses serializer reads that shared field to obtain
environmentand display dimensions. As a result, one run can serialize another run's computer configuration. If the first run completes and disposes its computer before the second run serializes, disposal restores the shared field to the provider and the second run fails with:The GA
computerpayload does not require these dimensions, so the observed serialization failure is specific to preview-compatible payloads. However, the provider lifecycle is documented and implemented as per-run state, so concurrent runs should not share mutable resolved-computer state.Debug information
v0.18.2andmainat7369b73cRepro steps
From a repository checkout, save the following as
repro_computer_concurrency.pyand run it withuv run python repro_computer_concurrency.py. It uses a local fake model and makes no API request:Observed output:
Run A serializes run B's width. When run A then performs cleanup, run B sees the provider instead of its resolved computer and fails during serialization.
Expected behavior
Each run should pass its own resolved
Computerinstance to model serialization and tool execution. Concurrent runs that reuse the sameAgentandComputerToolshould serialize their own dimensions, complete independently, and dispose exactly their own provider-created computer once.