Files
stack/packages/mosaic
Mos (Hermes) a4cbd4be51 fix(tools/git/pr-ci-wait): stdin collision in python3 - <<PY made wrapper always return "unknown"
When the wrapper invoked `python3 - <<'PY' ... PY` inside a function that
was being fed JSON via a pipe (`printf '%s' "$STATUS_JSON" |
extract_state_from_status_json`), the heredoc bound stdin to the Python
program text. The `-` argument tells Python to read its program from
stdin, so the program consumed stdin before json.load(sys.stdin) ran —
which then saw EOF and bailed to the "unknown" branch every time.

Result: pr-ci-wait.sh hung the full timeout (default 30 min) even when
the upstream Gitea status was already 'success', because every poll
returned 'unknown' and the loop kept retrying.

Fix: capture the piped JSON into a local variable with `payload=$(cat)`
BEFORE invoking python, then pass it via env (PR_CI_STATUS_JSON). The
heredoc still drives the Python program, but the payload is now read
from the environment instead of a stdin that's already been consumed.

Same fix applied to print_status_summary() which has the identical
pattern.

Verified locally:
  $ echo '{"state":"success"}' | extract_state_from_status_json → success
  $ echo '' | extract_state_from_status_json → unknown
  $ echo '{"state":null,"statuses":[{"state":"success"}]}' | … → success
  $ echo '{"state":"pending"}' | extract_state_from_status_json → pending
  $ echo '{"state":"failure"}' | extract_state_from_status_json → failure

Reported in screenshot from operator session 2026-05-13 — wrapper was
stuck waiting on a PR whose underlying Gitea status was already
success. Operator workaround was to bypass the wrapper and use the raw
Gitea API.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-13 18:30:52 -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="admin@example.com"
export MOSAIC_ADMIN_PASSWORD="securepass123"

mosaic gateway install

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.