--- title: "Sandbox Debugging" sidebarTitle: "Sandbox" description: "Hand it a failing test — it runs the code in an isolated workspace and reports back" icon: "terminal" --- import { SlackThread, SlackMessage, Mention } from "/snippets/slack-message.mdx"; ## The scenario A test is failing and the stack trace alone isn't enough. You want Company Brain to actually run the code, not just describe what it *would* do. ## What happens supermemory the `permissions.lease` unit test is failing on main — can you reproduce and tell me why? Reproduced in a sandbox against `main`. **Failure:** `permissions.lease` expects temporary access to expire in 15 minutes, but the fixture still asserts 30. **Cause:** the default was shortened in `#1188`; the unit test wasn't updated. **Fix:** point the assertion at the shared default so it can't drift again. ## What's really going on Company Brain spins up an **isolated workspace**, checks out what it needs, runs the command, and reads the output. It's not guessing from static code alone — it's executing. Guardrails are intentional, so it's safe to hand real tasks to: - No `git push`, no deploys - No elevated privileges (`sudo` and similar are blocked) - No reaching arbitrary internal network addresses - No long-running dev servers Think of it as a sealed workbench: useful for reproduce / inspect / explain loops, not for shipping changes on your behalf. When the next step is a Linear issue or a PR lookup. All the scenario walkthroughs.