Define the implementation job
AI coding agents receive the scoped request, relevant repository context, acceptance criteria, and verification target. They do not get a vague instruction to change anything they find.
An AI coding agent sandbox for work you can review.
Ghost can hand a bounded implementation brief to a coding agent, use a managed workspace for code and commands, run the relevant checks, and return changed files, logs, and results for review.
- Direct answer
- An AI coding agent sandbox is a scoped execution workspace where a coding agent can inspect a repository, edit files, install permitted dependencies, run builds and tests, and return a reviewable diff without treating the workspace as unrestricted access to the host computer.
One complete example.
For an Atlas export bug, Ghost gives the coding agent the affected repository and acceptance criteria, runs the targeted tests in the workspace, records the changed files and remaining failure, and returns the diff for review before any merge or release.
Where each capability enters.
This is one workflow across Ghost, not a bundle of disconnected products. Each feature owns a specific stage and keeps its own access boundary.
Run code in a managed workspace
The AI agent sandbox provides the repository-shaped environment, files, commands, dependencies, build output, and test logs needed to carry out the job.
Keep release as a separate decision
A passing build or live preview is not a public deployment. Publishing is a later, explicit workflow with its own readiness check, route verification, and release record.
How the work moves.
The handoff stays inspectable from source to result. Every stage names what it received, what changed, and what needs review.
Write the bounded brief
The user defines the problem, repository or managed app, allowed scope, acceptance criteria, and what evidence should count as complete.
Prepare the repository workspace
Ghost supplies the relevant code and task context to a managed environment. Host-side files or terminal work use the Computer boundary only when that access is genuinely required and approved.
Inspect before editing
The coding agent reads the relevant architecture, existing tests, and local conventions. The first step is understanding the change surface, not generating a replacement application.
Implement the scoped change
Files are edited inside the permitted workspace, dependencies are added only when needed, and commands remain tied to the requested outcome.
Build, test, and record evidence
The workflow runs the relevant formatter, targeted tests, build, or preview and keeps the logs. A passed unit test and a working browser preview answer different questions, so the result names what was actually checked.
Return reviewable changes
Ghost reports the changed files, diff, verification result, unresolved risks, and next action. Applying, merging, publishing, or deleting work remains a separate decision.
What the workflow does not assume.
Connected work still needs accurate sources, explicit destinations, and review where an action changes another person’s system.
- A sandbox reduces the execution surface but does not replace tool policy, user approval, code review, or verification.
- The page does not claim perfect containment, no network access, a particular microVM boundary, or universal reversibility.
- A finished coding task, a working preview, a merged change, and a public deployment are separate states.
Questions about coding agent sandbox.
What can an AI coding agent do in a sandbox?
Within the permitted workspace, it can inspect code, edit files, run shell commands, install allowed dependencies, build, test, and return the resulting diff and logs for review.
Does the coding sandbox have access to my whole Mac?
No such blanket access is implied. Managed sandbox work and approved host-side Computer or terminal work have different boundaries and should be used only when the task requires them.
Is sandboxed code automatically safe to merge?
No. Isolation does not make the implementation correct. The user should review the diff, verification evidence, dependency changes, and remaining risks before applying or merging it.
Does a passing test deploy the app?
No. Tests, previews, merges, and public releases are distinct states. Publishing requires a separate requested workflow and a verified live result.
Can the coding agent keep working after one failed test?
The workflow can inspect the failure and continue within the bounded task, but it should report unresolved errors rather than presenting a partial run as complete.
Start with one real workflow.
Bring the source, the intended result, and the boundaries that matter. Ghost is in private beta for macOS.
Request access