---
title: "Execute Workspace Bash"
method: POST
path: "/v1/kernel/workspace-bash"
tags: ["kernel"]
---

# Execute Workspace Bash

`POST /v1/kernel/workspace-bash`

Run a bash command on the box that serves the session's agent bash.

``/bash`` above proxies to *kernel* sandbox sessions and fails closed when
the kernel is gone — but on Modal the agent's own bash tool runs on the
**workspace sandbox** (see ``ModalKernelContext``), whose ``/local`` is a
sandbox-private rootfs no kernel session can see. A client that needs to
read what the agent's bash wrote (``--artifacts``) must therefore exec on
that box, through the same ``route_bash`` path the agent's tool uses, so
the two can never resolve to different filesystems.

``chat_session_id`` is required: it drives the same workspace-identity
resolution as the agent's bash (including isolated-run identity), and it
is validated against the caller so bash on another user's sandbox is
unreachable.

The session's stored sandbox-environment spec is installed as the ambient
scope for the call, exactly as ``generation_turn_runtime_scope`` does for
the agent's own bash. The workspace-sandbox *alias* is derived from that
spec (``ModalAgentBridge._workspace_alias``), so without it an isolated
run's command would land on the default box — a different filesystem from
the one the run wrote.

## Response `200`

Successful Response

- unknown

---

[API](https://skmtc.net/quadrillion/apis/quadrillion-cloud-api.md) · [All operations](https://skmtc.net/quadrillion/apis/quadrillion-cloud-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/quadrillion/quadrillion-cloud-api/revisions/ee473d0e84e0/schema)
