Add durable Strands sandbox support - #1768
Conversation
A timeout is the deterministic outcome the caller's own `timeout` argument asked for, so retrying just re-runs the same hanging command. Under Temporal's unlimited-attempt default this meant SandboxTimeoutError never reached workflow code and the agent could never observe the timeout and adapt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every built-in Strands sandbox raises a plain FileNotFoundError from read/write/remove — only list_files raises the SandboxPathNotFoundError subclass — so the old handlers were dead code and a missing path retried forever instead of reaching workflow code. Catch the documented base class instead, and carry the sandbox's own message through so a timeout reports the duration it actually enforced rather than the one the caller requested. Also fix the DockerSandbox import in the README, which is not re-exported from strands.sandbox, and note that the sandbox cache is per worker process. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
| # workflow | ||
| agent = TemporalAgent( | ||
| sandbox=TemporalSandbox( | ||
| "build", |
There was a problem hiding this comment.
Now that we are using SandboxWorkflowContext do we need the name?
| "build", |
There was a problem hiding this comment.
The name selects the corresponding sandbox defined in StrandsPlugin(sandboxes=...), whereas the context contains the Workflow ID.
There was a problem hiding this comment.
Could the factory function handle all sandbox retrievals instead of name map?
TemporalAgent(
sandbox=TemporalSandbox(start_to_close_timeout=timedelta(minutes=5))
)
...
plugins=[StrandsPlugin(sandboxes=build_sandbox)]There was a problem hiding this comment.
The name map is good because it's what we already do for MCP, and it allows us to have multiple sandboxes in the same environment.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 18d709b210
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| value: dict[str, Any] | ||
|
|
||
|
|
||
| class _SandboxRecord: |
There was a problem hiding this comment.
Can the cache be replaced with a call to the user-provided factory for every activity? The factory can then resolve the correct sandbox using the current context and implement caching appropriate to its backend. This would simplify the lifecycle and cancellation logic, and keep caching policy with the component that understands sandbox identity and cleanup.
There was a problem hiding this comment.
I like the idea in principle, but if you were making millions of tool calls you'd have millions of factory calls. It's possible that factory calls are expensive, which could force users to have to implement some type of caching mechanism in their factories to avoid the cost.
Summary
Testing