Skip to content

Lazy-boot sandbox instead of always initializing on startup #112

@sentry-junior

Description

@sentry-junior

Summary

The sandbox environment is booted on every request, even when the turn doesn't require it (e.g. simple text replies, config reads, reactions). This adds unnecessary latency and resource cost to interactions that never touch the sandbox.

Current behavior

The sandbox is initialized eagerly at the start of every turn, regardless of whether any tool that requires it (e.g. bash, readFile, writeFile) is actually invoked.

Gap

Many turns — simple Q&A, Slack reactions, channel posts, canvas updates — don't need a sandbox at all. Paying the boot cost unconditionally is wasteful and slows response time for the common case.

Options

  • Lazy boot on first sandbox tool call: defer sandbox initialization until the first tool that requires it is invoked. No-op turns pay zero cost.
  • Pre-warm pool: keep a pool of warm sandboxes ready to attach, reducing cold-start latency when the sandbox is needed.
  • Capability tagging: annotate tools with requires_sandbox: true so the runtime knows upfront whether to boot before execution begins.

Recommendation

Lazy boot on first sandbox tool call is the lowest-risk starting point. It requires no infrastructure changes and directly eliminates the cost for turns that never need the sandbox. Pre-warming can be layered on top later if cold-start latency remains a concern.

Action taken on behalf of David Cramer.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions