Repository navigation
chore: build development apps with their own identity at one fixed path (npm run dev-app) - #123
Merged
Merged
Conversation
…th, with npm run dev-app
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.
Development builds had the release identity (
dev.githubnext.desktop-tools) and ran from scattered build folders (12 copies under /tmp). macOS seems to ask again for its dated screen-capture approval ("bypass the system private window picker") per copy, so live runs stacked prompts. This follows Ace's approach (ace2 docs/desktop.md, UI testing).npm run dev-appbuilds Desktop Tools Dev.app with the bundle IDdev.githubnext.desktop-tools.dev, nested under the release ID as feat: ask once per agent before it controls the Mac, and keep agent input off Desktop Tools' own UI (#24) #120's self-target guard requires. The client is….dev.desktop-client;signnow takes the client identifier from the bundle's Info.plist, so release signing is unchanged.~/Library/Application Support/desktop-tools/dev/Desktop Tools Dev.app, shared by every checkout and worktree. A build stages a sibling folder, quits the running dev app, replaces the bundle in place and opens it withopen(LaunchServices), not by exec'ing the binary.npm run dev-app -- --stopquits it.~/.local/state/desktop-tools-devwhen its bundle ID ends in.dev, so it can't relink the installed app's client even when opened from Finder.DESKTOP_TOOLS_STATEstill overrides, and is passed throughopen --env. Approved agents (feat: ask once per agent before it controls the Mac, and keep agent input off Desktop Tools' own UI (#24) #120) live in that folder, so the dev app asks about each agent once, separately.DESKTOP_TOOLS_CODESIGN_IDENTITYor the git configdesktopTools.codesignIdentity, which all worktrees share. Ad-hoc signing is refused. On this Mac the config is set to the Developer ID SHA-1. The designated requirement staysidentifier "dev.githubnext.desktop-tools.dev" and anchor apple generic and …across rebuilds.Verified
npm run dev-appbuilt, signed and installed the app, and opened it. desktop_apps (installed release tools) showsdev.githubnext.desktop-tools.devrunning from the fixed path.DESKTOP_TOOLS_STATE=~/.local/state/desktop-tools-devanswered desktop_apps through it.npm run dev-appreplaced the running app in place, and the client connected again.--stopquit it, a second--stopreported nothing running, and no staging folder was left.For the user: this is a new identity, so macOS lists Desktop Tools Dev separately. It needs Accessibility, Screen Recording and Keyboard input granted once, plus one capture approval. Rebuilds keep them. Nothing in System Settings was clicked. The dev app is currently quit.