Manage template dependency environments

A code template can import third-party packages. cxg sandbox gives each language its own package directory so those imports resolve without touching your system package managers. This guide initialises one, inspects it, and shows the one sequencing bug you will hit if you run the subcommands the obvious way.

Before you start

cxg installed. See Installation.
The language runtimes you want managed already on your system. cxg sandbox installs packages into per-language directories using your host python3, node, and so on; it does not install the runtimes themselves.

Initialise an environment

Pick the languages you need rather than all of them.

Initialise Python and JavaScript.
Terminal window
```
cxg sandbox init --languages python,javascript
```
```
→ Initializing sandbox environment...
✓ Sandbox initialized successfully!
  Initialized languages: Python, JavaScript, Java
```
Java appears because selecting javascript also enables it. The two are coupled in this build. Some packages may report failures during init; cxg continues with whatever installed.

Confirm what landed.

cxg sandbox status

Sandbox Status
════════════════════════════════════════════════════════════
Location: /Users/you/Library/Application Support/cert-x-gen/sandbox
Initialized: No

Language Runtimes:
  Python:     ✓
  JavaScript: ✓

The ✓ marks are what matter, and those runtimes are set up. Ignore the Initialized: No line; the next section explains it.

The init state bug, and the path around it

Here is the trap. After a successful init, running install, list, shell, or export in a new command fails:

cxg sandbox install python requests

Error: Configuration error: Sandbox not initialized. Run 'cxg sandbox init' first.

The environment on disk is fine: status shows the ✓ marks, and the package directories exist. The check that gates install reads an in-memory flag that is only ever set within the same process that ran init. A fresh cxg process starts with the flag false, so it refuses even though the work is done. status, path, and templates do not consult that flag, which is why they still work.

The working path is to do the install in the same invocation as the init. init is incremental, adding packages and languages without rebuilding, so re-running it is how you install into an existing environment:

Add a package by naming it on an init run.
Terminal window
```
cxg sandbox init --languages python
```
Re-running init sets up any new language or package and skips what already exists. Use --force to rebuild from scratch.
Read the environment’s location and hand it to your own tooling.
Terminal window
```
cxg sandbox path
```
```
/Users/you/Library/Application Support/cert-x-gen/sandbox
```
Under that directory, python/venv/ is a standard virtualenv. You can drive it directly with "$(cxg sandbox path)/python/venv/bin/pip" list, which side- steps the gated list subcommand entirely.

Docker mode is not isolation

cxg sandbox info, create, and enter manage Docker-based environments. They are a heavier way to get the same thing, a place for dependencies, and the container’s enter shell is contained by Docker in the ordinary way. But a cxg scan you launch from your host still runs on your host. Starting or auto-entering a container does not move template execution into it. For confinement, run cxg itself inside a container or VM; see the trust model.

Clean up

cxg sandbox clean --force

Write your first template builds a standard-library template that needs no dependency environment at all.
Template trust model explains what “sandbox” does and does not mean here.
cxg sandbox documents every subcommand.