Files
stack/packages/mosaic
fred 585dac7a5d fix(launch): resolve the runtime binary once and execute the object that was checked
AMD1213-D defect D3. The fleet launch path asked `which` whether a runtime was
reachable and then spawned the bare name, letting the OS resolve it a second
time against an ambient PATH at a later moment. Two independent resolutions of
an attacker-influenced name with a gap in between is not a check.

Measured against the old code before changing it. A world-writable shim named
`codex` prepended to PATH:

    OLD checkRuntime  -> PASSED (which found it)
    OLD execRuntime   -> "SHIM EXECUTED -- this is not the real runtime"

The probe satisfied the check and then supplied the thing that ran.

Three call sites were exposed, not one: `checkRuntime`'s `which`; `execRuntime`
spawning 'codex'/'opencode' by name; and `execLeaseGatedRuntime` spawning
'python3' by name -- the interpreter that starts the lease gate itself, where a
shim does not bypass one check, it replaces the process that enforces all of
them. `minimalLaunchEnv` copies ambient PATH straight through, so the child
inherits the same search.

The fix: `resolveExecutableFromPath` searches only the PATH the child will
actually receive, validates the object the search lands on (regular file,
executable, not group/other-writable, owned by the launching user or root, with
no group/world-writable non-sticky directory and no foreign-owned directory on
its resolved path), and returns that path pinned to its dev/ino. Callers execute
the returned path, never the name again. Rules that are each a hole if dropped:
a relative PATH entry is skipped, since it resolves against wherever the
launcher was started; the first name match decides the outcome and an unsafe
first match is a refusal rather than a reason to keep looking, because falling
through would let a planted binary silently downgrade the search to whatever
came after it; a symlink is followed and the real file is what gets validated
and executed, since validating the link and executing the name repeats the
original bug one level down.

`checkRuntime` is kept unchanged on the operator path. `which` proves
reachability from the operator's own shell, which is the right question there
and the wrong one for a seat. The fleet lease-gate interpreter now comes from
the root-owned `trustedCapability('python3')` the helper already requires.

Two residuals, stated rather than engineered around:

  * `assertUnchangedSinceValidation` re-confirms dev/ino immediately before
    spawn. That narrows the validation-to-exec window; it does not close it.
    Closing it means executing a held descriptor and Node has no portable way to
    exec by descriptor. A same-UID replacement landing inside the remaining
    window is the same accepted boundary already documented for the fleet
    helper.
  * For claude and pi the runtime binary is still re-resolved inside
    launch-runtime.py after the trusted interpreter starts it. This change does
    not cover that path.

Twelve tests in launch.spec.ts, each written against a specific hole: safe
resolution; world-writable binary; safe binary under a world-writable
directory; no fall-through past an unsafe first match; relative PATH entry
ignored; symlink followed and real file validated; symlink to an unsafe target
refused; non-executable refused; directory sharing the name refused; a path
rather than a name refused; no PATH declared; not-found reported as not-found
rather than resolving something else.

One of those tests was written wrong first and is worth recording: creating the
open directory with `mkdirSync(path, { mode: 0o777 })` gets masked by the umask
to 0o755, so the case passed while testing nothing. It creates at 0o755 and
chmods after.

Verification: typecheck RC=0. Full package suite 1615 passed / 4 failed / 1619.
The four failures are the pre-existing host lease-identity leak into spawned
hooks, not this change -- the same spec re-run with only the five MOSAIC_LEASE_*
and MOSAIC_RUNTIME_GENERATION variables stripped from the environment, with no
code change, is 20/20.

Scope note: this commit carries the uncommitted D1/D4/D6 work already present in
the tree alongside D3, because it is interleaved in the same files and is one
amend package. D2 and D5 are not yet assessed.

Commit-only per scrappy's controlling packet (comms 20260813T212447Z dc43de):
not pushed, PR #1213 not updated, nothing re-authored.
2026-08-15 14:07:57 -05:00
..

@mosaicstack/mosaic

CLI package for the Mosaic self-hosted AI agent platform.

Usage

mosaic wizard           # First-run setup wizard
mosaic gateway install  # Install the gateway daemon
mosaic config show      # View current configuration
mosaic config hooks list  # Manage Claude hooks

Headless / CI Installation

Set MOSAIC_ASSUME_YES=1 (or ensure stdin is not a TTY) to skip all interactive prompts. The following environment variables control the install:

Gateway configuration (mosaic gateway install)

Variable Default Required
MOSAIC_STORAGE_TIER local No
MOSAIC_GATEWAY_PORT 14242 No
MOSAIC_DATABASE_URL (none) Yes if tier=team
MOSAIC_VALKEY_URL (none) Yes if tier=team
MOSAIC_ANTHROPIC_API_KEY (none) No
MOSAIC_CORS_ORIGIN http://localhost:3000 No

Admin user bootstrap

Variable Default Required
MOSAIC_ADMIN_NAME (none) Yes (headless)
MOSAIC_ADMIN_EMAIL (none) Yes (headless)
MOSAIC_ADMIN_PASSWORD (none) Yes (headless)

MOSAIC_ADMIN_PASSWORD must be at least 8 characters. In headless mode a missing or too-short password causes a non-zero exit.

Example: Docker / CI install

export MOSAIC_ASSUME_YES=1
export MOSAIC_ADMIN_NAME="Admin"
export MOSAIC_ADMIN_EMAIL="[email protected]"
export MOSAIC_ADMIN_PASSWORD="securepass123"

mosaic gateway install

Runtime launchers

mosaic claude            # Launch Claude Code with Mosaic injection
mosaic yolo claude       # …with --dangerously-skip-permissions
mosaic codex | opencode | pi

mosaic claudex (EXPERIMENTAL)

Runs GPT models inside the Claude Code harness by pointing Claude Code at a local claude-code-proxy that translates the Anthropic Messages API to a ChatGPT-subscription (Codex OAuth) backend. This is not Anthropic Claude — model behavior, tool use, and output quality may differ. Intended for evaluation, not production delivery.

mosaic claudex           # launch (prompts through the proxy readiness gate)
mosaic yolo claudex      # …with --dangerously-skip-permissions
mosaic claudex --print "hello"   # trailing args are forwarded to Claude Code

Prerequisite: the claude-code-proxy binary must be installed and authenticated (claude-code-proxy codex auth …). mosaic claudex runs a preflight that verifies the binary, the OAuth state (triggering a device re-auth if needed), and a trusted local listener before launching; it fails closed if the proxy cannot be brought up with a verified identity.

Isolation (never touches your real Claude state). claudex always launches against an isolated CLAUDE_CONFIG_DIR (default ~/.config/mosaic/claudex/home). The ambient CLAUDE_CONFIG_DIR is deliberately ignored, and a guard proves the resolved dir can never be — or live under — the real ~/.claude. A claudex session therefore cannot mutate your normal Claude Code config.

No token leakage. claudex never reads the proxy's credential file. Claude Code is handed only ANTHROPIC_AUTH_TOKEN=unused pointed at the loopback proxy; the entire credential-bearing env family (ANTHROPIC_*, AWS_*, GOOGLE_CLOUD_*, GOOGLE_APPLICATION_CREDENTIALS, *_TOKEN, *_KEY, *_SECRET, …) is stripped from the composed environment. The Bedrock/Vertex routing switches (CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, and the _SKIP_*_AUTH pair) are force-removed regardless of value — otherwise their mere presence would route Claude Code to the real Anthropic API via AWS/GCP and bypass the proxy. The proxy holds the real OAuth credential.

Model tiers (override via env).

Tier Env var Default
primary (opus/sonnet) ANTHROPIC_MODEL gpt-5.6-sol
small/fast (haiku) ANTHROPIC_SMALL_FAST_MODEL gpt-5.6-luna

Operator-provided values win over the defaults. Additional overrides: MOSAIC_CLAUDEX_CONFIG_DIR (isolated config dir), ANTHROPIC_BASE_URL (proxy endpoint).

Hooks management

After running mosaic wizard, Claude hooks are installed in ~/.claude/hooks-config.json.

mosaic config hooks list              # Show all hooks and enabled/disabled status
mosaic config hooks disable PostToolUse  # Disable a hook (reversible)
mosaic config hooks enable PostToolUse   # Re-enable a disabled hook

Set CLAUDE_HOME to override the default ~/.claude directory.