# trusty-cage CLI Enhancements for Automation

These changes make trusty-cage usable by automated callers (like the `cage-orchestrator` Claude Code skill) that can't interact with prompts.

---

## 1. `--auth-mode` flag on `create`

**Current behavior:** `trusty-cage create` prompts interactively for auth mode selection:

```
Select authentication mode:
1. api_key
2. oauth
> _
```

**Workaround today:** `echo "1" | trusty-cage create ...` — fragile, breaks if menu order changes.

**Requested change:** Add `--auth-mode <mode>` flag that skips the interactive prompt.

```bash
# Desired usage
trusty-cage create https://github.com/user/repo --name my-env --auth-mode api_key --no-attach
```

**Accepted values:** Should match the existing menu options (e.g., `api_key`, `oauth`).

**Behavior:** When `--auth-mode` is provided, skip the interactive selection entirely. When omitted, show the prompt as today (backwards-compatible).

---

## 2. `--yes` / `-y` flag on `export`

**Current behavior:** `trusty-cage export` asks for confirmation before exporting:

```
Export environment 'my-env'? [y/N] _
```

**Workaround today:** `echo "y" | trusty-cage export my-env`

**Requested change:** Add `--yes` / `-y` flag to skip confirmation.

```bash
# Desired usage
trusty-cage export my-env --yes
```

---

## 3. `--yes` / `-y` flag on `destroy`

**Current behavior:** `trusty-cage destroy` asks for confirmation before destroying:

```
Destroy environment 'my-env'? [y/N] _
```

**Workaround today:** `echo "y" | trusty-cage destroy my-env`

**Requested change:** Same `--yes` / `-y` flag pattern.

```bash
# Desired usage
trusty-cage destroy my-env --yes
```

---

## 4. Set `TRUSTY_CAGE=1` environment variable in containers

**Current behavior:** There is no standard way for code running inside a cage to know it's inside a cage.

**Why it matters:** The user's dotfiles (including Claude Code skills) get copied into the container. Some skills — like `cage-orchestrator` itself — must not run inside a cage (it would try to spin up a cage inside a cage). Currently the skill checks `whoami == trustycage` as a heuristic, but that's tied to a username convention and breaks if the container user changes.

**Requested change:** trusty-cage should set `TRUSTY_CAGE=1` as an environment variable in every container it creates. This gives any tool, script, or skill a reliable, explicit signal that it's running in an isolated cage environment.

```bash
# Inside a cage container
echo $TRUSTY_CAGE  # "1"

# On the host
echo $TRUSTY_CAGE  # "" (unset)
```

**Where to set it:** In the Dockerfile or container entrypoint — wherever trusty-cage configures the container environment.

**Benefits over `whoami` check:**
- Explicit intent vs. username convention
- Works even if the container user is renamed
- Any tool can check it, not just skills that know about the `trustycage` user
- Follows the same pattern as `CI=true`, `DOCKER=1`, etc.

---

## Why This Matters

The `cage-orchestrator` skill lets an "outer" Claude Code on the host delegate autonomous work to an "inner" Claude Code running inside a trusty-cage container. The full lifecycle is automated: create cage, launch inner agent, monitor, export results, overlay onto host repo.

Every interactive prompt in that pipeline is a break point that requires a piped-input hack. These three flags turn trusty-cage into a first-class automation target — not just for this skill, but for any scripted workflow that wants to use cages programmatically.

The piped-input workarounds are fragile because:
- Menu order changes break `echo "1"` silently (wrong auth mode selected)
- If prompt wording changes, the workaround may not match expected input
- Piped input can behave differently across shells and CI environments
