Skip to content

Add durable Strands sandbox support - #1768

Open
brianstrauch wants to merge 15 commits into
mainfrom
strands-temporal-sandbox
Open

Add durable Strands sandbox support#1768
brianstrauch wants to merge 15 commits into
mainfrom
strands-temporal-sandbox

Conversation

@brianstrauch

Copy link
Copy Markdown
Member

Summary

  • add an experimental activity-backed TemporalSandbox implementation for the Strands sandbox API
  • register lazy, worker-lifetime sandbox factories through StrandsPlugin
  • buffer execution streams for deterministic replay and optionally publish raw StreamChunk values through Workflow Streams
  • preserve Strands timeout and missing-path errors across the activity boundary
  • vend the standard sandbox bash and file-editor tools with user overrides
  • document lifecycle, payload, retry, streaming, and environment-value considerations

Testing

  • poe test -s -k strands
  • poe lint
  • git diff --check

@brianstrauch
brianstrauch requested review from a team as code owners August 20, 2026 02:48
@brianstrauch
brianstrauch requested a balanced review from Copilot August 20, 2026 03:02

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

brianstrauch and others added 4 commits August 20, 2026 16:22
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>
@patbeqo

patbeqo commented Aug 27, 2026

Copy link
Copy Markdown

@codex

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Swish!

Reviewed commit: ef2c383e3c

ℹ️ 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".

Comment thread temporalio/contrib/strands/README.md Outdated
# workflow
agent = TemporalAgent(
sandbox=TemporalSandbox(
"build",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we are using SandboxWorkflowContext do we need the name?

Suggested change
"build",

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name selects the corresponding sandbox defined in StrandsPlugin(sandboxes=...), whereas the context contains the Workflow ID.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)]

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread temporalio/contrib/strands/_sandbox_activity.py
@brianstrauch
brianstrauch requested a review from patbeqo August 31, 2026 16:11
@patbeqo

patbeqo commented Sep 1, 2026

Copy link
Copy Markdown

@codex

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 1, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-01T14:23:58.272519Z 18d709b Manual request
ℹ️ 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" or "@codex security review".

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 chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread temporalio/contrib/strands/_sandbox_activity.py Outdated
Comment thread temporalio/contrib/strands/_sandbox_activity.py Outdated
Comment thread temporalio/contrib/strands/_sandbox_activity.py Outdated
Comment thread temporalio/contrib/strands/_plugin.py Outdated
value: dict[str, Any]


class _SandboxRecord:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@brianstrauch
brianstrauch requested a review from patbeqo September 1, 2026 21:01
@patbeqo
patbeqo requested a review from a team September 4, 2026 13:11

@xumaple xumaple left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good but provided some comments

self, operation: str, input: Any, *, result_type: type | None = None
) -> Any:
input.sandbox_name = self._name
input.first_execution_run_id = workflow.info().first_execution_run_id

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using first_execution_run_id here is operationally convenient, but it means the sandbox isolation key is not entirely derived from trusted Activity metadata. Arbitrary workflow code on the same task queue can invoke the named Activity and choose a first-execution Run ID. If workflow IDs are reused, or if multiple trust domains share workers, that can potentially reconnect to another chain’s backing environment.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should at least be documented even if we consider workflow code to be trusted.

def _has_record(self, key: _SandboxKey, record: _SandboxRecord) -> bool:
return self._records.get(key) is record

def _evict(self, key: _SandboxKey, record: _SandboxRecord) -> None:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eviction removes _SandboxRecord, but it does not close the resulting sandbox or adapter. aclose() also awaits creation
and then discards the object.

That may be harmless for DockerSandbox if it is only a lightweight identifier, but other implementations may own HTTP
clients, WebSockets, subprocess handles, tunnels, or leases. How are we planning to handle that?



def _timeout_error(err: SandboxTimeoutError, timeout: float | None) -> ApplicationError:
# A timeout is the deterministic outcome the caller asked for, so retrying

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A timeout is the deterministic outcome the caller asked for

It is? Isn't timeout the definition of something we should retry?

ExecutionResult,
FileInfo,
Sandbox,
StreamChunk,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Raw StreamChunk values lack:

  • sandbox name;
  • workflow operation/execution ID;
  • Activity attempt;
  • chunk sequence;
  • command versus code execution.

That makes a shared topic difficult to consume correctly. “Use different topics” pushes correlation onto callers and
becomes awkward for concurrent agent tool calls.

I would publish an envelope such as:

SandboxStreamEvent(
sandbox_name=...,
execution_id=...,
attempt=...,
sequence=...,
chunk=...,
)

All arguments and results cross Temporal's payload boundary and enter workflow
history. Keep command output and files within the server's configured payload
size limits; use external storage for large artifacts. In particular, `env`
values are recorded in history and must not contain secrets.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this suggests that we should maybe use a secret reference system the same way that we did for openai sandboxing?

activities do not construct a `WorkflowStreamClient` and the workflow does not
need to host a `WorkflowStream`.

All arguments and results cross Temporal's payload boundary and enter workflow

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like when we put things like "cross Temporal's activity boundary" or the like into docs/readmes. llms love to use this type of language but for users who are not super familiar with temporal, this can be very confusing. Prefer pointing to things being "serialized into workflow history" I think that makes a lot more sense for a wider audience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants