RepoPrompt CE ships three install paths with three different signing stories, and its ad-hoc debug build forgets your keys

Three install paths, three different signing stories

The Homebrew route is the only one that yields a signed and notarized app:

brew tap repoprompt/repoprompt-ce
brew install --cask repoprompt-ce

That cask consumes a promoted public updater ZIP rather than compiling anything, and lands `/Applications/RepoPrompt CE.app` on disk. The debug route instead double-clicks `Launch RepoPrompt CE.command` in Finder and drives a coordinator that rebuilds and relaunches the app. The local production route double-clicks `Install RepoPrompt CE Local Production.command`, builds from source, and replaces whatever is already in `/Applications` with a build signed by a dedicated self-signed certificate that macOS may ask you to approve. That last result is described as local only, not notarized, and not something to copy to another Mac or redistribute.

Ad-hoc debug builds keep API keys in memory only

When no `Apple Development:` identity is present, the documented fallback signs ad hoc:

ALLOW_ADHOC_SIGNING=1 ./conductor app relaunch

Those builds use in-memory secure storage, so saved API keys and secure permission changes do not survive a relaunch. The way out is to hand the launcher a stable identity instead:

SIGN_IDENTITY="Apple Development: Your Name (TEAMID)" ./conductor app relaunch

That gives debug builds persistent Keychain storage. The condition is that the identity already exists on the machine, with the team id typed in by hand. The practical difference is that whether your debug session keeps working after a rebuild comes down to your local keychain rather than to a preference inside the app.

The launcher refuses a no-Python fallback on purpose

The Finder launcher is not a thin wrapper, and the reason is stated rather than implied. Double-clicking `Launch RepoPrompt CE.command` opens a small terminal window that stays available with four keys bound: `r` rebuilds and relaunches, `s` shows app status, `x` stops the app, and `q` closes the launcher without stopping the app. Both rebuild and stop go through a coordinated developer daemon instead of touching the app directly, and lifecycle actions validate the exact debug executable path, which is why there is no uncoordinated fallback when Python is missing. Python 3 is therefore a hard requirement of this route. On Xcode selection, the launcher preserves an explicitly compatible `DEVELOPER_DIR` or picks an installed full Xcode for its own process, and it never changes the system-wide `xcode-select` setting.

The debug app may rebuild itself while you are editing it

Using RepoPrompt CE to modify RepoPrompt CE is not a quiet loop. The guidance warns that when the debug app is used to change the project itself, validation flows that launch the app or run live smoke checks may rebuild and relaunch it, and that the app should be expected to restart while those checks run. The build machinery behind that is substantial. The Makefile's phony list runs to more than fifty targets, mixing plain names such as `doctor`, `resolve`, `build`, `run`, `test`, `guardrails` and `clean` with a parallel set of `dev-` prefixed variants. `doctor` verifies local Swift and Xcode setup, `guardrails` runs source layout and repository guardrails, and `codex-schema-check` validates bounded app-server assumptions against generated Codex schemas.

make xcode generates a disposable workspace with four schemes

Contributors who want Xcode get a generated workspace rather than a checked-in project:

make xcode

In Xcode 26.3 the choice is between `RepoPrompt CE App` for the packaged debug app, `RepoPrompt CE MCP` for the coordinated MCP executable, and `RepoPrompt CE Tests`. The test scheme delegates to conductor because `RepoPromptMCP` is an executable-only SwiftPM target that Xcode will not drive by itself. Underneath, Xcode also exposes the native `RepoPrompt` and `repoprompt-mcp` product schemes, which is why four names show up where three are documented. Release packaging ignores the generated workspace entirely, so it is a convenience layer for daily contributor work rather than part of how a build ships.

Licensing spans a LICENSE, notices, a vendor tree and a resolved file

The Apache-2.0 grant is only the first of several root entries. Beside `LICENSE` sit `THIRD_PARTY_NOTICES.md` and a `ThirdPartyLicenses/` directory, and the dependency story is made of a `Vendor/` directory, a `Packages/` tree and a committed `Package.resolved` that pins what was resolved. Maintainers track release signing, Sparkle update metadata, dependency pins and third-party notices in `docs/open-source-readiness.md`, which makes the update channel auditable rather than implicit. Version state is spread across three more root files, `version.env`, `release-rollout.json` and `tip-rollout.json`, so the version a build reports is not read from a single location.

Source builds need macOS 26 and a full Xcode, not just the tools

The stated floor is macOS 26 or later plus either Xcode 26 or matching Command Line Tools carrying the macOS 26 SDK. The stricter part is what follows: the Finder debug launcher and the local production installer both require the full Xcode application, not the command line tools alone. That gap matters, because someone reading only the SDK requirement would reasonably assume the tools suffice. The local production installer goes one step further and selects a compatible installed Xcode for its own process, again leaving the system-wide `xcode-select` untouched. In practice that difference decides which of the two `.command` files you can double-click at all on a given machine.

MCP progress reporting only fires when the client sends a token

The Context Builder lets an agent explore a repository, identify relevant files and curate them inside a token budget, and long-running MCP calls expose request-scoped progress, but only when the client supplies a progress token. A client that sends none gets silence for the duration of the call. Alongside it, Context Composer is for reviewing selected files and codemaps, configuring prompt packaging and Git context, and copying a fresh model-ready prompt without leaving Agent Mode. What both draw on is the same set of inputs: file trees, selected file contents, line slices, CodeMaps and Git diffs. Agent orchestration runs CLI-backed coding agents from the app, with app-managed worktrees and `.worktreeinclude` for copying local files into them, and a workspace can span several related repositories at once.

Editorial conclusion

RepoPrompt CE fits a macOS-only team that wants an agent to read the repository before it writes, and wants to see the file selection and diffs before anything is sent. Prefer the Homebrew cask, since it is the only route that produces a signed and notarized app and the only one that does not need Python. Avoid the local production installer unless you intend to keep that app on that Mac, and if you build from source, set `SIGN_IDENTITY` before you save any API key, because an ad-hoc debug build keeps them in memory only. Confirm macOS 26 and a full Xcode install first, and expect the app to relaunch itself when validation flows run against a build you are editing.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes