Skip to content

Merge dev → main: native installers + browser MCP off by default#79

Merged
UmarFarooq75 merged 11 commits into
mainfrom
dev
May 7, 2026
Merged

Merge dev → main: native installers + browser MCP off by default#79
UmarFarooq75 merged 11 commits into
mainfrom
dev

Conversation

@UmarFarooq75
Copy link
Copy Markdown
Collaborator

Summary

Promotes the installer + safety changes from `dev` to `main`.

What lands:

After merge, the README's `raw.githubusercontent.com/.../main/scripts/install.sh` URL resolves and the legacy curl-pipe path keeps working alongside the new native installers. Future cleanup (deleting the curl-pipe scripts since the native installers are the recommended path) can be a follow-up commit.

Test plan

UmarFarooq75 and others added 11 commits May 7, 2026 01:41
Two install scripts that download Node, install daemora globally, and
create a desktop shortcut so non-technical users can get from "click
this command" to a running dashboard with no follow-up steps.

- scripts/install.sh — macOS + Linux. Detects Node 22+, installs via
  Homebrew (macOS) or apt/dnf/pacman (Linux) if missing. npm install -g
  daemora. Creates /Applications/Daemora.app on macOS, ~/.local/share/
  applications/daemora.desktop on Linux. Launcher waits for the HTTP
  port before opening the browser.
- scripts/install.ps1 — Windows. Same flow via winget. Creates Desktop
  + Start Menu .lnk shortcuts pointing at a launcher .bat that hides
  its console window.

First run hits `daemora start`, which already runs the setup wizard if
config isn't done. Subsequent runs detect the running port and just
open the browser. Default port 8081, override with DAEMORA_PORT.

README updated with the curl | bash and irm | iex one-liners under a
new "One-line install (recommended for non-developers)" section above
the existing npm path, which stays for developers.
## Summary
Two install scripts so a non-technical user can go from
copy-paste-a-command to a running Daemora dashboard with no follow-ups.

- **`scripts/install.sh`** (macOS + Linux): detects Node 22+, installs
via Homebrew (macOS) or apt/dnf/pacman (Linux) if missing, runs `npm
install -g daemora`, creates `/Applications/Daemora.app` on macOS or
`~/.local/share/applications/daemora.desktop` on Linux, and launches the
agent. Launcher waits for the HTTP port before opening the browser.
- **`scripts/install.ps1`** (Windows): same flow via winget. Creates
Desktop + Start Menu shortcuts pointing at a launcher `.bat` that hides
its console window.

First run uses `daemora start`, which already runs the existing setup
wizard if config isn't done. Subsequent runs detect the running port and
just open the browser. Default port `8081`, override with
`DAEMORA_PORT`.

README updated with the one-liners under a new **One-line install
(recommended for non-developers)** section above the existing npm path.
The npm path stays for developers.

## How users run it

**macOS / Linux**
```bash
curl -fsSL https://raw.githubusercontent.com/CodeAndCanvasLabs/Daemora/main/scripts/install.sh | bash
```

**Windows** (PowerShell)
```powershell
irm https://raw.githubusercontent.com/CodeAndCanvasLabs/Daemora/main/scripts/install.ps1 | iex
```

## Test plan
- [x] `bash -n scripts/install.sh` — syntax clean
- [ ] **macOS**: clean machine without Node — run `curl … | bash`,
confirm Homebrew + Node install, confirm `Daemora.app` appears in
`/Applications`, confirm browser opens to `localhost:8081`, confirm
second click on the app icon reuses the running server
- [ ] **macOS**: machine with Node 22+ already installed — confirm Node
step is skipped
- [ ] **Linux** (Ubuntu/Debian): clean machine — confirm apt install
path, `.desktop` entry shows in app launcher
- [ ] **Linux** (Fedora): confirm dnf path
- [ ] **Linux** (Arch): confirm pacman path
- [ ] **Windows**: clean machine — `irm … | iex` from PowerShell,
confirm winget installs Node, confirm Desktop + Start Menu shortcuts
created, confirm browser opens
- [ ] First-launch wizard renders correctly on each platform
- [ ] Subsequent launches skip the wizard and load the dashboard
directly
Browser tools are now opt-in. Until the user enables Playwright from
the MCP settings UI, neither the main agent nor the browser-pilot crew
sees browser_navigate/click/screenshot/etc. The intent is that browser
work routes through use_crew("browser-pilot", ...) deliberately rather
than the main agent reaching for browser tools unprompted.

When the user does enable it, both the main agent and browser-pilot
get the tools simultaneously — current architecture is single MCP
server, shared catalog. (Per-crew MCP scoping would be a separate
larger change.)
## Summary
Flip Playwright MCP's default \`enabled\` from \`true\` to \`false\`.
Browser tools become opt-in — neither the main agent nor the
browser-pilot crew sees \`browser_navigate\`, \`browser_click\`,
\`browser_screenshot\`, etc. until the user explicitly enables the
Playwright server from the MCP settings UI.

## Why
The main agent shouldn't reach for browser tools unprompted. The intent
is:
- Browser work → \`use_crew(\"browser-pilot\", ...)\` deliberately
- Main agent stays focused on orchestration

When the user enables Playwright via the UI, both the main agent and
browser-pilot get the tools back simultaneously (current architecture is
single shared MCP server, no per-crew scoping yet — that's a separate
larger change tracked elsewhere).

## Affected behaviour
- **Fresh installs**: no browser tools by default. User clicks Enable in
MCP settings → tools restored to both the main agent and browser-pilot.
- **Existing users**: their \`mcp.json\` already has \`enabled: true\`
from when they first installed; this PR doesn't migrate that. They keep
browser tools unless they manually disable.

## Test plan
- [x] \`npx tsc --noEmit\` clean
- [ ] Fresh install: confirm Playwright doesn't show in the agent's tool
list
- [ ] Enable Playwright from MCP settings: confirm \`browser_*\` tools
reappear, browser-pilot can run
- [ ] Disable again: confirm both surfaces lose the tools
Original script used `sudo` to write into /Applications, but curl|bash
has no TTY — sudo couldn't read a password and the .app bundle silently
failed to create. User ran the installer, daemora ran fine, but no app
icon ever appeared.

Two fixes layered:
1. osascript with administrator privileges shows a GUI password dialog
   that works in non-TTY shells (same trick Homebrew/Anthropic/Cursor
   installers use). User sees a real macOS auth prompt.
2. If they cancel or osascript isn't available, fall back to
   ~/Applications/Daemora.app. User-writable, no sudo, indexed by
   Spotlight + Finder. Only downside: not in Launchpad (only
   /Applications is). Better than no icon at all.

Either way the .app gets created — `mdimport` triggers Spotlight to
index it immediately so 'Daemora' is searchable right after install.
…t -u was treating … as part of the variable name and failing with 'unbound variable' on the very line that defined it
…ripts (#78)

## Summary
Brings in proper native installers for macOS and Windows — replacing the
curl-pipe scripts I added in #75.

**macOS** (\`installer/macos/\`):
- Pre-built \`Daemora.app\` template with a real 309 KB \`.icns\` icon
- Companion \`Stop Daemora.app\`
- \`build-pkg.sh\` produces a signed \`.pkg\` installer
- \`preinstall\` / \`postinstall\` scripts handle the installation
properly
- Native \"open the .pkg, click Continue, done\" experience

**Windows** (\`installer/windows/\`):
- Inno Setup script (\`daemora.iss\`)
- Pre-built \`DaemoraSetup.exe\` (2 MB)
- \`launcher.ps1\` with the right launcher behavior
- Real \`.ico\` icon

**Tooling:** \`scripts/build-installer-icons.mjs\` programmatically
generates platform icons from source — no manual icon babysitting.

## Why this over the curl-pipe scripts
- Real native UX (no terminal commands, no \`curl | bash\`)
- No sudo-in-non-TTY problems, no \`Daemora.app\` creation failing
silently
- Real signed installer bits → no Gatekeeper friction
- Icon, code-signing, version metadata all baked in
- Win10/11 native experience via Inno Setup

## Action item after merge
Delete the now-redundant curl-pipe scripts on \`dev\`:
- \`scripts/install.sh\` (added in PR #75 + my fixes \`1cf856f\` and
\`f61032a\`)
- \`scripts/install.ps1\` (added in PR #75)

The installers branch was based on \`main\` (before #75 merged into
dev), so those files won't conflict — they'll just remain after the
merge. A follow-up commit deletes them.

## Test plan
- [ ] macOS: open the generated \`.pkg\`, complete the wizard, confirm
\`Daemora.app\` lands in /Applications with the icon, double-click
launches the dashboard
- [ ] Windows: run \`DaemoraSetup.exe\`, complete the wizard, confirm
Start Menu + Desktop shortcuts with icon, double-click launches
dashboard
- [ ] Stop \`Daemora.app\` (macOS) cleanly stops the running agent
- [ ] Uninstaller cleanly removes the app on both platforms
…e build script

Two real issues found while testing the .pkg locally on an Apple
Silicon Mac with Homebrew:

1. postinstall failed with `EACCES: permission denied, mkdir
   /usr/local/lib/node_modules/daemora`. Root cause: macOS users
   default to zsh, where Homebrew shellenv lives in ~/.zprofile /
   ~/.zshrc. The scripts use `sudo -u <user> -H bash -lc …` which
   only sources bash profiles — Homebrew's PATH/prefix isn't set,
   so npm falls back to the Intel default /usr/local/lib instead
   of /opt/homebrew/lib (the actual Homebrew prefix on Apple
   Silicon). mkdir then EACCES'es because /usr/local/lib isn't
   user-writable.

   Fix: source `brew shellenv` explicitly in run_as_user before any
   command, picking /opt/homebrew/bin/brew or /usr/local/bin/brew
   depending on architecture. Same change applied to preinstall
   (same helper, same bug) so node detection / install also works.

2. build-pkg.sh was committed without the executable bit. BUILD.md
   instructs the developer to `chmod +x` first; flipping the mode
   in the repo makes the build a clean one-liner.
…licates

Two related fixes for the duplicate "Daemora" / "Stop Daemora" entries
showing up in Spotlight + Launchpad alongside the real /Applications
copies:

1. Rename source bundles `app-template/Daemora.app` →
   `Daemora.app-template` (and same for Stop Daemora). Spotlight
   classifies anything ending in `.app` as an Application; renaming
   the source dirs in the repo means contributors who clone don't
   pollute their own Spotlight index. build-pkg.sh now restores the
   `.app` extension during the cp into the payload, so the .pkg
   output is unchanged.
2. `.metadata_never_index` at `installer/macos/` covers the entire
   subtree, including the transient `build/payload/Applications/*.app`
   dirs that the build script produces. Spotlight respects the
   marker recursively.

Plus the README updated to point at the .pkg / .exe download path
instead of the old curl-pipe scripts (the native installers are now
the recommended non-tech path).
- package.json: 1.0.0-alpha.4 → 1.0.0-alpha.5 to mark the installer
  + Playwright-MCP-default-off changes as a new alpha cut.
- crew/video-editor/template/public/logo.png →
  crew/video-editor/template/public/DaemoraLogo.png. Same bytes,
  rename only, so the file matches the canonical asset name used
  elsewhere in the repo.
@UmarFarooq75 UmarFarooq75 merged commit d3205e8 into main May 7, 2026
4 checks passed
UmarFarooq75 added a commit that referenced this pull request May 7, 2026
## Summary
Single commit on dev that didn't make PR #79's window — adds an explicit
\`.gitignore\` exception for \`installer/macos/dist/**\` and commits the
built \`Daemora.pkg\` (554 KB) so non-technical users can download it
directly from the GitHub file tree until we set up Releases.

This matches the existing Windows convention —
\`installer/windows/Output/DaemoraSetup.exe\` is already tracked. The
macOS dist dir was unintentionally caught by the global \`dist/\` ignore
rule.

## Test plan
- [x] After merge, \`Daemora.pkg\` should be visible at
\`installer/macos/dist/Daemora.pkg\` on the main branch
- [x] Direct GitHub download URL:
https://github.com/CodeAndCanvasLabs/Daemora/raw/main/installer/macos/dist/Daemora.pkg
should resolve
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants