chore: Remove sandbox cli commands

Author: pthurlow

Cargo.lock

@@ -60,7 +60,6 @@ flate2 = "1"
 tar = "0.4"
 semver = "1"
 sqlformat = "0.5.0"
-sysinfo = { version = "0.38.4", default-features = false, features = ["system"] }
 self_update = { version = "0.42", default-features = false, features = ["rustls"] }
 lzma-rs = "0.3"
 tempfile = "3"

Cargo.toml

@@ -76,7 +76,6 @@ API key priority (lowest to highest): config file → `HOTDATA_API_KEY` env var
 | `embedding-providers` | `list`, `get`, `create`, `update`, `delete` | Manage embedding providers used by vector indexes |
 | `results` | `list` | Retrieve stored query results |
 | `jobs` | `list` | Manage background jobs |
-| `sandbox` | `list`, `new`, `set`, `read`, `update`, `run` | Manage sandboxes |
 | `skills` | `install`, `status` | Manage the hotdata agent skill |
 
 ## Global options
@@ -321,28 +320,6 @@ hotdata jobs <job_id> [--workspace-id <id>] [--format table|json|yaml]
 - `--job-type` accepts: `data_refresh_table`, `data_refresh_connection`, `dataset_refresh`, `create_index`, `create_dataset_index`.
 - `--status` accepts: `pending`, `running`, `succeeded`, `partially_succeeded`, `failed`.
 
-## Sandboxes
-
-Sandboxes group related CLI activity (queries, dataset operations, etc.) under a single context.
-
-```sh
-hotdata sandbox list [-w <id>] [-o table|json|yaml]
-hotdata sandbox <sandbox_id> [-w <id>] [-o table|json|yaml]
-hotdata sandbox new [--name "My Sandbox"] [-o table|json|yaml]
-hotdata sandbox set [<sandbox_id>]
-hotdata sandbox read
-hotdata sandbox update [<sandbox_id>] [--name "New Name"] [--markdown "..."] [-o table|json|yaml]
-hotdata sandbox run <cmd> [args...]
-hotdata sandbox <sandbox_id> run <cmd> [args...]
-```
-
-- `list` shows all sandboxes with a `*` marker on the active one.
-- `new` creates a sandbox and sets it as active.
-- `set` switches the active sandbox. Omit the ID to clear the active sandbox.
-- `read` prints the markdown content of the current sandbox.
-- `update` modifies the name or markdown of a sandbox (defaults to the active sandbox).
-- `run` runs a command with the hotdata CLI scoped to a sandbox. Creates a new sandbox unless a sandbox ID is provided before `run`. Useful for launching an agent that can only access sandbox data. Nesting sandboxes is not allowed.
-
 ## Configuration
 
 Config is stored at `~/.hotdata/config.yml` keyed by profile (default: `default`).

README.md

@@ -117,8 +117,3 @@ hotdata indexes create --connection-id <id> --schema <schema> --table <table> \
 
 List and delete use the same `hotdata indexes` commands as in the search skill; only **`--type sorted`** is the analytics focus here.
 
----
-
-## Sandboxes and chains
-
-Sandbox datasets use **`datasets.<sandbox_id>.<table>`**, not `datasets.main`. Run queries with active sandbox config or `hotdata sandbox <id> run hotdata query "..."`. See **`hotdata`** skill **Sandboxes**.

skills/hotdata-analytics/SKILL.md

@@ -84,30 +84,20 @@ Note the printed **`full_name`** (e.g. `datasets.main.chain_revenue_slice` or `c
 
 ### 3. Chain query
 
-Query using that name — do not hardcode `datasets.main` if the schema segment is a sandbox id:
+Query using the actual `full_name` from create or list — do not hardcode `datasets.main`; use whatever qualified name was printed:
 
 ```bash
 hotdata datasets list
 hotdata query "SELECT * FROM datasets.main.chain_revenue_slice WHERE ..."
-# Sandbox example (use actual full_name from create or list):
-# hotdata query "SELECT * FROM datasets.s_ufmblmvq.chain_revenue_slice WHERE ..."
 # Managed database:
 # hotdata query "SELECT * FROM chain_db.public.revenue_slice WHERE ..."
 ```
 
-### Sandbox context
-
-For **sandbox-scoped** chain tables:
-
-- Qualified name is **`datasets.<sandbox_id>.<table>`**, not `datasets.main`.
-- Run queries with **active sandbox** in config (`hotdata sandbox set`) **or** inside **`hotdata sandbox <sandbox_id> run hotdata query "…"`**.
-- Without sandbox context, you may get **access denied** on sandbox-only tables.
-
 ### Naming and documentation
 
 - Prefer predictable `--table-name` values: `chain_<topic>_<YYYYMMDD>`.
 - Record long-lived chains in **context:DATAMODEL → Derived tables (Chain)** with the **full** SQL name you use (`datasets.…` or `database.schema.table`).
-- Promote join/grain findings to **context:DATAMODEL** when they should outlive the sandbox (**`hotdata`** skill).
+- Promote join/grain findings to **context:DATAMODEL** when they should be shared or persisted (**`hotdata`** skill).
 
 ### Guardrails