nandi/oripublic Fork 0
5d476ff5f3dc3b7db3afaccaedc7d9661981449e
Commits
Clone
git clone https://git.rickub.com/nandi/ori.git
git clone ssh://git@rickub.com/nandi/ori.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

forked from bots-garden/ori

🛟 Updated. f5c963a · on 5d476ff5f3dc3b7db3afaccaedc7d9661981449e · k33g · yesterday
2026-09-18-launch-ori-applescript.md · 25 lines · 1.9 KBmarkdown
Blame HistoryOpen raw

2026-09-18 — AppleScript launcher (scripts/launch-ori.applescript)

State

Written, compile-checked, handlers tested in isolation. Not yet run end to end — that needs Docker Desktop + a real sbx run, which creates the sandbox and starts Claude inside it. First real run to do by the user: osascript scripts/launch-ori.applescript.

Things to confirm on the first real run

  • Behaviour of sbx run -d --name ori when the sandbox is already running (unknown: no-op or error?). The script only notifies on error there and relies on the health check, so either way the app should open; tighten if the notification is noisy.
  • Time for the kit to start the server after sbx run -d returns; budget is 90 s (healthTimeoutSeconds), adjust if the template pull makes the first launch slower.
  • display notification from a compiled app may need notification permission the first time.

Traps

  • do shell script PATH: fine from a terminal (inherits the shell), minimal from Finder — hence the explicit export PATH.
  • sbx inspect/sbx ports on a missing sandbox print ERROR: but their exit code was masked in my probe; sbx ls -q (names only) is the reliable existence test.
  • Handlers can be tested without running on run: osacompile -o /tmp/x.scpt … then load script + call s's waitForServer(...).

Update (same day) — double-clickable app

scripts/Launch Ori.app built with osacompile -o "scripts/Launch Ori.app" scripts/launch-ori.applescript; gitignored (scripts/*.app/), rebuild after editing the .applescript. path to me then resolves to the .app bundle inside scripts/, so the repo root still derives correctly. The app has no quarantine attribute (built locally), so Gatekeeper does not block it. Still not run end to end.

Update — README

scripts/README.md (EN) and scripts/README.fr.md (FR) document the launcher; keep them in sync with the property defaults at the top of the script if those change.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 2026-09-18 — AppleScript launcher (`scripts/launch-ori.applescript`)

## State

Written, compile-checked, handlers tested in isolation. **Not yet run end to end** — that needs Docker Desktop + a real `sbx run`, which creates the sandbox and starts Claude inside it. First real run to do by the user: `osascript scripts/launch-ori.applescript`.

## Things to confirm on the first real run

- Behaviour of `sbx run -d --name ori` when the sandbox is already **running** (unknown: no-op or error?). The script only notifies on error there and relies on the health check, so either way the app should open; tighten if the notification is noisy.
- Time for the kit to start the server after `sbx run -d` returns; budget is 90 s (`healthTimeoutSeconds`), adjust if the template pull makes the first launch slower.
- `display notification` from a compiled app may need notification permission the first time.

## Traps

- `do shell script` PATH: fine from a terminal (inherits the shell), minimal from Finder — hence the explicit `export PATH`.
- `sbx inspect`/`sbx ports` on a missing sandbox print `ERROR:` but their exit code was masked in my probe; `sbx ls -q` (names only) is the reliable existence test.
- Handlers can be tested without running `on run`: `osacompile -o /tmp/x.scpt …` then `load script` + call `s's waitForServer(...)`.

## Update (same day) — double-clickable app

`scripts/Launch Ori.app` built with `osacompile -o "scripts/Launch Ori.app" scripts/launch-ori.applescript`; gitignored (`scripts/*.app/`), rebuild after editing the `.applescript`. `path to me` then resolves to the `.app` bundle inside `scripts/`, so the repo root still derives correctly. The app has no quarantine attribute (built locally), so Gatekeeper does not block it. Still not run end to end.

## Update — README

`scripts/README.md` (EN) and `scripts/README.fr.md` (FR) document the launcher; keep them in sync with the `property` defaults at the top of the script if those change.