Merge dev → main: native installers + browser MCP off by default#79
Merged
Conversation
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.
2 tasks
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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