Code Execution Sandbox

PebbleAI ships with a platform-hosted code execution sandbox that runs user-provided code — today via Skills, with more runtimes planned — inside strong isolation, with persistent sessions, network controls, and per-user file storage. It’s one of PebbleAI’s key differentiators against the public AI products.

Why it exists

Public AI products like Claude, GPT, and Copilot can reason about code and generate it, but they can’t run persistent user code for you. That’s fine for one-shots; it’s a dead end for production workflows where you want an AI to build an Excel file, run a data analysis, generate a branded PDF, or test a web app and return the results.

PebbleAI’s sandbox closes that gap. A Python-using Skill can produce a PDF, save it to your file store, and return a download link — all inside the chat round-trip. No desktop handoff, no file upload, no “please run this yourself”.

What it runs

Skills with .js/.ts files still import and the prose can reference them — the code itself just won’t run in the sandbox until Node is wired up.

Persistent sessions

Each chat gets its own isolated sandbox session. The key word is persistent: variables you define in the first Python call are still there on the second, third, and twentieth. This is how an agent can write a short block of setup code, run it, then run a follow-up that depends on the first block’s variables — without having to re-establish state.

Sessions are per-user and per-chat. Cross-user session access is a hard error enforced at every layer — another user’s sandbox and its state are invisible to you.

Resource limits per session

Multiple users running skills simultaneously each get their own isolated session. A short-running skill that’s just formatting a file comfortably fits in these limits; a large data analysis may need to be broken into steps.

Security posture

The sandbox runs user-provided code, so the security model is layered:

Process isolation

• Every syscall from the sandboxed process is intercepted and handled in user space — no direct access to the host kernel.
• Runs as an unprivileged user with all Linux capabilities dropped.
• Read-write filesystem is limited to the session workspace; everything else is read-only.

Network isolation

• Default-deny egress. A freshly spawned sandbox has no network access at all.
• Admins configure an allow-list per skill or per session. A skill that needs to call api.example.com must explicitly declare it and an admin must approve it.
• Internal hosts (*.internal, *.svc.cluster.local) are always blocked — even explicit allow-lists can’t reach them.

Code security

Before a skill is stored, it runs through a security scanner that blocks shell injection, disallowed binaries, oversize files, and known exfiltration patterns. See PebbleChat → Skills for the skill-author view. The scanner is applied regardless of source — GitHub import, URL import, zip upload, or direct creation.

Credential isolation

• Credentials are injected into sandbox sessions only on explicit opt-in.
• The platform verifies that every credential referenced by a session is owned by the same user the session belongs to. Cross-user credential references are rejected before the sandbox is even scheduled.
• Audit logs record every mounted secret per session.

Per-user file storage

Sandbox output files (PDFs, images, spreadsheets) are uploaded to per-user storage. Download URLs are unguessable capability URLs — a user cannot enumerate another user’s files. See User Settings → File Store for the user-facing view.

Observability

Every sandbox execution is audited:

• Live activity — execution steps stream back to PebbleChat in real time, so the user sees the sandbox activity in the Activity Stream.
• Audit logs — user, session, executed code, duration, exit status, mounted secrets, and allowed egress — logged to the standard PebbleAI logging pipeline.
• PebbleObserve integration — cost, latency, and error rates appear alongside the rest of your usage in PebbleObserve → Usage.

Admin controls

As an organisation admin you can:

• Enable or disable the sandbox for your organisation from Organisation → Settings → Capabilities.
• Approve or block individual skills that use the sandbox.
• Review usage and cost via PebbleObserve → Usage.

Differentiation — why this matters

PebbleAI’s sandbox combines things that none of the public AI products offer together:

• ✅ Platform-hosted code execution — no desktop handoff
• ✅ Multi-user — session isolation enforced at every layer
• ✅ Persistent sessions — variables survive across calls
• ✅ Per-user file storage — output files land somewhere durable
• ✅ Integrated with Skills — prompt templates and code in one unit
• ✅ Sovereign — runs inside your own infrastructure, in the region you chose

The nearest alternative is Claude’s Code Interpreter, which is US-based, not multi-tenant to your organisation, has no persistent per-user storage, and can’t be extended with your own Skills. GPT Code Interpreter has similar constraints. Copilot has no code execution model at all.

Related

• PebbleChat → Skills — user-facing view of skills that use the sandbox
• User Settings → File Store — where output files land
• Admin → Capabilities — how admins provision the Skills capability
• PebbleObserve → Usage — sandbox cost and activity tracking
• Activity Stream — user-visible sandbox execution steps