Skip to main content
The Code Sandbox gives your agent the ability to execute Python code and shell commands in a secure, isolated cloud environment. It is natively enabled on all agents with no configuration required.

What the Sandbox Can Do

Run Python Code

Data analysis, visualizations, computations, file processing, API calls, and more.

Execute Shell Commands

File operations, package installation, running scripts, and system commands.

Read & Write Files

Create, modify, and organize files within the sandbox filesystem.

Upload & Download

Move files between your Gumloop storage and the sandbox environment.

How It Works

Each conversation runs in its own secure cloud sandbox (an isolated VM). The files your agent creates while working stay with that conversation, so if you reopen the chat later they are restored automatically. Anything that should outlive a single chat lives in one of two durable layers that carry over across all conversations with the same agent: the shared package environment and the agent’s workspace folders.
Python variables and imports remain available while the conversation’s Python kernel is running. They are not archived with files and may be lost if the kernel or sandbox is restarted. Save important intermediate results to files so the agent can reload them.
Starting a new conversation gives you a fresh working directory, but your installed packages and workspace files are already available from previous sessions.

Pre-installed Packages

The sandbox comes with 80+ Python packages ready to use, so your agent can start working immediately without installing anything.
pandas, numpy, scipy, scikit-learn, statsmodels
matplotlib, seaborn, plotly, bokeh
openai, anthropic, google-generativeai, mistralai, llama-index-core, gensim
requests, aiohttp, beautifulsoup4, scrapy, selenium, playwright
openpyxl, PyMuPDF, python-docx, Pillow, opencv-python, imageio
moviepy, librosa, ffmpeg-python, yt-dlp, soundfile
nltk, spacy, textblob
psycopg2-binary, pymongo, PyMySQL, pyodbc, boto3, google-cloud-storage
Need something that isn’t pre-installed? Your agent can install it with pip install package-name. Installed packages are shared across every chat on the agent, so you only need to install once. Members with edit access to the agent can add packages for everyone; if you only have view access, your own installs are temporary and last for the current session.

Execution Limits

The sandbox is designed for data analysis, scripting, and automation tasks. It is not intended for training large ML models or running persistent servers.

Examples

Here are some common ways to use the Code Sandbox:
Ask your agent to analyze data:
The agent will use pandas to load the data, perform analysis, and generate visualizations with matplotlib or plotly.

Workspace Files

The agent has two persistent workspace folders that carry over across conversations:
  • Team workspace (.workspace/agent/) — shared by everyone with access to the agent. Files saved here by one member are visible to all other members, which makes it ideal for reference data, configuration, or ongoing project assets. Members with edit access can write to it; members with view access can read it but not change it.
  • Personal workspace (.workspace/personal/) — private to you. Files you save here persist across your own conversations with the agent and are never visible to other members.
Your agent chooses the right folder automatically based on whether a file should be shared or kept private, so you can simply ask it to save something for later. Workspace files follow the same artifact system as other agent-generated files: they are versioned, previewable, and shareable.
For more details on file management, versioning, and sharing, see Agent Artifacts.

Integration with Apps

The sandbox has access to your connected apps via the pre-installed gumloop SDK. Your agent can call any of its configured integrations directly from Python code:
This means your agent can combine code execution with any integration, for example: query a database, process the results in Python, then post a summary to Slack.

Agent Secrets

Agent Secrets let you inject encrypted credentials into the sandbox as environment variables, so your agent can authenticate with external services (APIs, databases, etc.) without ever exposing the raw values. A secret is the stored credential, either personal or owned by a team. A binding maps an environment-variable name on an agent to a secret. Binding scope controls who gets that mapping; it does not change who owns the secret.

Adding a Secret to Your Agent

1

Open the Agent tab and add a secret

Open the agent, go to the Agent tab, expand Secrets, and click + Add.
Secrets section showing No secrets yet and an Add button
2

Name it and pick a source

In Add personal secret to agent, set Name to the environment-variable name the agent should use (for example PYLON_API_KEY). Under Source, choose Existing secret or New secret, then pick or create the stored credential.
Add personal secret to agent dialog with Name, Source, and Secret fields
Click Add. The secret appears by name in the Secrets section. The agent can use it at runtime as an environment variable, but it never sees the raw value.
3

Prompt the agent to use the secret

In the agent chat, ask it to perform a task that requires the credential. The agent accesses the secret as an environment variable (e.g. os.environ["PYLON_API_KEY"]) and uses it in code, but it can never read or expose the actual value.
Agent chat showing it has access to PYLON_API_KEY and using it to query the Pylon API for tickets created today
If you share an agent that uses personal secrets, other users will be prompted to provide their own values. Your secrets are never exposed.

Two Types of Secrets

Personal Secrets

Private to you. No other user can access them. Managed from your personal secrets settings.

Team Secrets

Shared across all team members. Available when an agent is in a team space.

Team Secrets

For agents in a team space, you can use shared secrets that all team members can access.
1

Move agent to a team space

Move your agent into a team (or create it there).
2

Add a team secret

On the Agent tab, expand Secrets and click + Add. The picker shows both personal and team secrets.
3

Select a team secret

Pick from the Team Secrets section. All team members will share this value.
Secret picker showing Personal Secrets and Team Secrets sections with Pylon API Key under Team Secrets

Binding Scopes

Bindings can be saved for User or Team scope in Secrets on the Agent tab: The scope toggle offers Team and User. The panel describes them as:
  • Team scope: “Anyone in your team who uses this agent can use these secrets. A user binding with the same name overrides these.”
  • User scope: “Only you can use these secrets. User secrets override matching team secrets.”
If you can read team bindings but cannot manage team secrets, you can see the Team list but are prompted to request the required permission instead of adding a binding. A personal agent with no home team can only have user bindings, so the Team option is not offered.

Runtime Resolution

Secrets resolve based on the running user, not the agent owner. A user who runs an agent without a binding of their own is prompted to configure one. For each run, the authorized home-team bindings are merged with the running user’s bindings. If the same environment-variable name exists in both, the user binding wins. Team bindings are skipped when the running user does not have permission to read the home project, so users outside that team do not get them. Permissions are checked again when bindings are used, not only when they are saved. When a user encounters a secret they haven’t configured, the chat prompts them to configure it:
Chat showing Configure secrets prompt with PYLON_API_KEY needed, a dropdown to select from Personal Secrets or add new, and buttons for Skip, Save for me, and Save to agent
When the agent asks you to bind secrets mid-chat, the prompt asks Who should use these bindings? Options:
  • Skip: proceed without the secret
  • Only me: the binding applies to you
  • My team: the binding applies to everyone on the agent’s home team; offered only when the agent has a home team and you can manage the team’s variables
If the question goes unanswered, the binding is saved for you only, so access is never widened by accident.
Users can also manage their active secrets during a conversation using the Secrets button in the chat composer:
Chat composer Secrets popover showing Your secrets with Pylon API Key mapped to PYLON_API_KEY

Comparison

Secret Ownership

Binding Scope


FAQ

No. Secrets are injected as environment variables at runtime. The agent can reference them by name (os.environ["MY_KEY"]) but never sees the actual value. Values are encrypted and never shown to the agent.
Yes. An agent can use personal and team secrets, and it can have both user and team bindings. Team bindings require a home team and the appropriate project access. If you run an agent with a binding you haven’t configured, the chat prompts you to bind your own (see Runtime Resolution).
Your user binding wins. The running user’s bindings override authorized team bindings with the same environment-variable name.
Anyone on the agent’s home team who can use the agent and has read access to the home project can use the binding. Permissions are checked again when the binding is used.
The agent may not have a home team, or you may not have permission to manage the project’s variables. Personal agents with no home team offer user bindings only.
It can use user bindings only. Team scope is not available without a home project/team.
Yes. Secrets are bound to the agent configuration. They are available every time the agent runs code.
Go to gumloop.com/settings/profile/secrets and add one. It will then appear in the secret picker when configuring agents.