@sellable/install 0.1.250 → 0.1.252

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.250",
+  "version": "0.1.252",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-evergreen-campaigns.md

@@ -310,13 +310,21 @@ acceptable only when it writes a fresh durable per-lane receipt artifact as it
 works.
 When visible Codex app thread tools are unavailable but local Codex CLI is
 available, the accepted durable streaming-worker command shape is:
-`codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> -`.
+`codex -a never -s danger-full-access exec -m <worker-model> -C <repo> -o <worker-final-file> -`.
 The approval and sandbox flags must come before the `exec` subcommand for Codex
 CLI builds that expose `-a`/`-s` only at top level. Do not use
 `codex exec --ask-for-approval never ...` or `codex exec -a never ...`; those
 forms fail on current customer CLI installs. Pipe the lane packet prompt on
 stdin, require the worker to write `workerDispatch.receiptArtifactHint`, and
 pass exactly one lane packet per worker.
+When launching durable Codex CLI workers from an automation parent, pass an
+explicit supported worker model instead of relying on the Codex CLI default
+model. Use the parent runtime model when known, for example:
+`codex -a never -s danger-full-access exec -m <worker-model> -C <repo> -o <worker-final-file> -`.
+Do not rely on the Codex CLI default model; some customer and VPS installs
+default to unavailable model aliases. If the parent cannot identify a supported
+worker model and a test `codex exec -m <worker-model>` launch is rejected, stop
+with `blocked: worker_model_unavailable` before mutation.
 When wrapping multiple local Codex CLI workers in a shell launcher, run the
 wrapper with `/bin/bash -lc` or another explicitly chosen portable shell. Do not
 rely on zsh-specific behavior. Do not use `status` as a shell variable because
@@ -328,7 +336,7 @@ Do not embed `<<'WORKER_PROMPT'` heredocs inside a single quoted or double
 quoted `/bin/bash -lc '...'` command string; nested quoting is brittle and can
 truncate the first worker before mutation. For multi-worker launchers, write one
 plain prompt file per lane under the current run directory, then start each
-worker with `codex -a never -s danger-full-access exec -C "$REPO" -o
+worker with `codex -a never -s danger-full-access exec -m "$WORKER_MODEL" -C "$REPO" -o
 "$worker_final_file" - < "$worker_prompt_file"`. Keep launcher shell variables
 double-quoted and keep the prompt heredoc only in a standalone script/prompt-file
 write step, not inside an already quoted shell argument. If the first launcher
@@ -386,7 +394,7 @@ launchers, write the same prompt body to `<worker-prompt-file>` and launch the
 worker with stdin redirected from that file:
 
 ```
-codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
+codex -a never -s danger-full-access exec -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
 Use $sellable:create-evergreen-campaigns as the governing skill for this one lane worker.
 
 Workspace id: <workspaceId>
@@ -409,7 +417,7 @@ Complete only this lane, write the required durable receipt JSON, and stop.
 WORKER_PROMPT
 
 # Multi-worker launcher equivalent:
-codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> - < <worker-prompt-file>
+codex -a never -s danger-full-access exec -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
 ```
 
 If any placeholder cannot be filled from the current lane packet, do not inspect