Run Your First Agent
OpenShell can run an AI agent or another autonomous command when its executable is available in the sandbox image. The image, provider profile, and policy define what the workload can execute and access. OpenShell does not require the agent to use a specific framework or model API.
Prepare the Workload
An agent needs three pieces:
Build and maintain an OCI image for each workload. Install the agent, shell, development tools, CA certificates, and language runtimes that the workload needs. Use pinned versions so you can review and reproduce image updates.
The --from option also accepts a local rootfs archive. It does not build a
Dockerfile or directory. Refer to
Custom Containers for image and
runtime details. The fallback image contains no agent or development toolchain,
so pass your image explicitly for agent workloads.
Prepare Provider Access
A provider profile defines the credentials and endpoints an agent uses. The gateway serves only profiles that an administrator or user has imported. Review a profile before importing it, especially its executable paths and network endpoints.
The repository includes example profiles in
providers/. Copy
and adapt an example when the agent binary is installed at another path or uses
a different service endpoint. Refer to Profiles for the
profile schema and import workflow.
Launch the Agent
Pass the agent command after -- and attach the provider instances it needs.
For example, this command starts Claude Code from an image your team built with
the claude executable installed:
The command before -- configures the sandbox. The command after -- becomes
the sandbox’s main process. OpenShell keeps the sandbox after that process exits
unless you pass --no-keep.
Use --detach for an unattended or long-running agent:
Use a profile-backed provider for credentials that the agent should not read
directly. Plain values passed with --env are visible to the agent process.
Build an Agent Image
Prepare each agent as part of your normal container build and release process:
- Select a trusted base image and install the agent executable and tools.
- Create or adapt provider profiles for every external service the agent uses.
- Add policy rules for required files, child processes, package registries, tool servers, and other network destinations.
- Build, scan, sign, and publish the image to a registry the gateway can pull.
- Launch the executable as the sandbox’s main process.
Provider profiles can contribute endpoint and executable rules to the effective policy. They do not grant unrelated network or filesystem access. Use Customize Sandbox Policies when the agent needs access beyond its attached providers.
Verify and Troubleshoot
Inspect the sandbox, effective policy, provider attachments, and logs:
If the executable is missing, change the sandbox image. If a provider request is denied, confirm that the profile names the actual endpoint and executable path. For another denied network or filesystem operation, update the sandbox policy after reviewing the requested access.
Next Steps
- For sandbox lifecycle, resources, templates, files, and connectivity, refer to Sandboxes.
- For the restrictive fallback policy, refer to Default Policy.
- For operating-system and runtime requirements, refer to the Support Matrix.