instabox 0.8.30 → 0.8.32

package/cli/SHA256SUMS

@@ -1,6 +1,6 @@
-9ddd7645215ae0b80c842bb4e3247327db5459a250d58344b0774b44cfc60802  instabox-darwin-amd64
-db8b842ace871cb1c2e4496b9de242e0d271210cfe77f6dd2177332d6a5292f5  instabox-darwin-arm64
-7555ff69ea85f04fea96845d2309e232d1acd5b2debad882d42825e7f1b80cf6  instabox-linux-amd64
-bf4bea7b5ddb1ce9e60c149a61f1eaff36a7ae0f22a0d1ea551cfbf6a7b8ff0d  instabox-linux-arm64
-7377ac2f7d607647765937973873f4efcd11e125fc06ed33e245454b7d419492  instabox-windows-amd64.exe
-97d00e9b08c612d963302137e6ca086b6802c1e62930d4a9a47fd8a96bf8a7f2  instabox-windows-arm64.exe
+35ca4c9b3dab1469e8bce7eb9cd80c06b3beb427d5b004c2b97140fd649543df  instabox-darwin-amd64
+5716033224fda228360c06603c4096d31b1c9a5206c60d11dd49be7afbf97503  instabox-darwin-arm64
+f1198ad6558a5f17d7d1c0e27dd0afb86a6a4b4b0c6b0ef1f2bc7a582e7e0304  instabox-linux-amd64
+f9380ff88cbee5e88bf7a88bc6e11144eecd28b1639a675e16b5e0ba1dddb790  instabox-linux-arm64
+bafc4abbc34054c57603b1efd2b4010f4706022b146a75b82013aac007066267  instabox-windows-amd64.exe
+c586a7a852bec3e0016038f6250151cb2f493944da4785db83efd861710f2cbf  instabox-windows-arm64.exe

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instabox",
-  "version": "0.8.30",
+  "version": "0.8.32",
   "description": "A cloud box for your coding agent, the instabox CLI and its agent skills in one command: npx instabox@latest",
   "type": "module",
   "bin": {

package/skills/instabox/SKILL.md

@@ -82,7 +82,7 @@ instabox rm --yes work                          # delete the box (without --yes
 - For large uploads use `instabox push` or `instabox cp` (the HTTP API, parallel-friendly), not scp or rsync over `ssh.instabox.sh`, which keeps about 2 MiB in flight per connection and so slows with distance. Measured: at a 5 ms round trip both paths do ~104 MB/s; at 305 ms the API does 11-13 MB/s per stream and SSH 3-6 MB/s; 4 parallel API PUTs did 39 MB/s total.
 - `create` options: `--template T` or `--snapshot S`, `--vcpus N --mem-mib M` (a size of the plan, see Sizes), `--auto-suspend D|0`, `--max-run-minutes N`, `--delete-after D` (delete it D after creation, 1m-24h, whatever its state), `--meta K=V`, `--org O`, `--secrets all|NAME,NAME|none`, `--no-wait`, `--setup-file PATH|-` (`--wait-setup`), `--fail-fast` (when no host has room, fail at once and create nothing instead of failing the create after; with `--snapshot`, instead of creating it stopped).
 - `create --setup-file PATH` (`-`: stdin; at most 64 KB) runs that script in the new box once it is running, in HOME as the box's user (by its `#!` line, else with bash; CRLF line endings become LF), and prints its output; it replaces create + push + exec for provisioning. A failing script makes `create` exit with the script's code and keeps the box: debug it with `instabox exec work -- /tmp/instabox-setup.sh`. With `--json` the sandbox object gets a `setup` object (`exitCode`, `stdout`, `stderr`, `signal`, `timedOut`, `truncated`, `durationMs`). `create` always waits for the script (`--wait-setup` names that; `=false` is refused) and keeps its state in the box's metadata, so `instabox get work --json` shows it later: `metadata.setupStatus` (`pending`, `running`, `succeeded`, `failed`), `setupExitCode` (`124`: timed out) and `setupLog` (the last 512 characters of its stdout then stderr). The script is killed after `--setup-timeout` (default and at most 10m); for longer installs, use `ssh`. A missing, empty or over-64 KB file is refused before any box is created. `run --setup-file` does the same before its command, with its `-e` variables; when the script fails, run's `--json` `exitCode` is the script's. The script stays at `/tmp/instabox-setup.sh` (and in snapshots), so keep credentials out of it.
-- `create --devcontainer [PATH|DIR]` (also `run --devcontainer`) builds a box from a repo's devcontainer.json (default `.devcontainer/devcontainer.json` or `.devcontainer.json` here; JSONC): it pushes the repo into `workspaceFolder` (default `/workspaces/<dir>`), writes `containerEnv`/`remoteEnv` to `/etc/profile.d/instabox-devcontainer.sh`, installs `features` via their install.sh (ones the template already has, such as node/python/go/docker-in-docker/github-cli at the default version, are skipped), and runs `onCreateCommand`/`updateContentCommand`/`postCreateCommand`/`postStartCommand` in the workspace. Do not install the Dev Containers CLI in a box for this. `image`/`build`/compose are not booted (boxes are VM templates); the summary (stderr, or `--json`'s `devcontainer`: `applied`, `skipped`, `ports`, `steps`, `status`, `failedStep`) says what was skipped, and `forwardPorts` come with `instabox port-forward`/`port publish` commands. A failed step exits with its code and keeps the box (`metadata.setupStep` names it); `--name` defaults to the config's name. `${devcontainerId}` is the box's name; the summary shows commands as written (a `${localEnv:TOKEN}` is not printed), but the profile file keeps env values (readable by root and the box user's group, and in snapshots). In `run`, write `--devcontainer=PATH` when a command follows without `--`.
+- `create --devcontainer [PATH|DIR]` (also `run --devcontainer`) builds a box from a repo's devcontainer.json (default `.devcontainer/devcontainer.json` or `.devcontainer.json` here; JSONC): it pushes the repo into `workspaceFolder` (default `/workspaces/<dir>`), writes `containerEnv`/`remoteEnv` to `/etc/profile.d/instabox-devcontainer.sh` (login shells, nested `bash -l` and `instabox ssh BOX -- cmd` all get it; `PATH` entries appear once), installs `features` via their install.sh (ones the template already has, such as node/python/go/docker-in-docker/github-cli at the default version, are skipped), and runs `onCreateCommand`/`updateContentCommand`/`postCreateCommand`/`postStartCommand` in the workspace. Do not install the Dev Containers CLI in a box for this. `image`/`build`/compose are not booted (boxes are VM templates); the summary (stderr, or `--json`'s `devcontainer`: `applied`, `skipped`, `ports`, `steps`, `status`, `failedStep`) says what was skipped, and `forwardPorts` come with `instabox port-forward`/`port publish` commands. A failed step exits with its code and keeps the box (`metadata.setupStep` names it); `--name` defaults to the config's name. `${devcontainerId}` is the box's name; the summary shows commands as written (a `${localEnv:TOKEN}` is not printed), but the profile file keeps env values (readable by root and the box user's group, and in snapshots). In `run`, write `--devcontainer=PATH` when a command follows without `--`.
 - Idle auto-pause defaults to 30 minutes. Paid boxes allow 5, 10, 15, 20, 25 or 30 minutes (a time between rounds up; below 5m or above 30m is refused, nothing created), or `0` to turn it off. Free boxes keep 30 minutes unless an admin grants an idle override; asking another value on a free box fails (`permission_denied`, nothing created), so leave `--auto-suspend` out there. Idle means no agent working, no terminal use and little CPU.
 - Max run minutes is independent of idle activity: `-1` is unlimited, `0` pauses immediately, and a positive integer forces a pause after that many running minutes. Free boxes have a fixed 480-minute cap that only an admin session can change; paid boxes default to `-1` and can change it. An idle override does not permit changes to a free box's runtime cap. The first limit reached pauses the box; both timers restart after sleep and wake.
 - A runtime pause blocks every wake path during a server-configured cooldown, 10 minutes by default. Wait until the `cooldownUntil` deadline shown by `instabox get`; edits cannot clear it. Afterward, an automatically paused box wakes on `exec`, `ssh`, `files`, a public port request or `instabox wake <box>`. A zero runtime cap must be changed before waking. A normal pause preserves memory and processes.