RepoPrompt CE: a native macOS context builder for coding agents

The problem: agents guess at a codebase they cannot see

A coding agent that starts from a bare instruction has to discover the repository itself. It greps, opens files, and burns turns deciding what matters. RepoPrompt CE takes the opposite stance: a human, or an agent under a token budget, curates the context first, and the prompt that reaches the model is something you can read before it is sent.

The README frames this as context engineering and lists the inputs it combines: file trees, selected file contents, line slices, CodeMaps, and Git diffs. The intended user is a developer running CLI-backed coding agents on macOS who wants a reviewable handoff rather than an opaque one. It is not a hosted service and not a chat client. It is a native app plus a bundled MCP server, and the second half matters as much as the first.

How RepoPrompt CE assembles context and exposes it over MCP

The architecture splits into two surfaces. The app is the workspace: multi-root, so related repositories, packages and documentation folders can sit in one view. The MCP server is the interface: MCP-compatible clients and CLI agents connect to it to search repositories, inspect files, curate context, run agent sessions, and orchestrate work.

Two named components do the curation. Context Builder lets an agent explore the repository, identify relevant files, and curate context within a token budget, with request-scoped progress reported when the client supplies a progress token. Context Composer is the human-facing side: review selected files and codemaps, configure prompt packaging and Git context, then copy a model-ready prompt without leaving Agent Mode. Agent orchestration runs CLI-backed agents from the app, and docs/worktrees.md covers app-managed worktrees plus .worktreeinclude for copying local files into them.

That split is the design decision worth noticing. The budget is enforced during selection, not after, so the agent is not handed a repository dump and asked to be economical. The trade-off is that curation quality depends on CodeMaps and on the selection rules, and the README points to docs/architecture/context-composer.md for those invariants rather than restating them.

Installing RepoPrompt CE with Homebrew and running a first session

The README gives two setup paths and says you do not need to open Xcode for either. The signed and notarized public app comes from a dedicated Homebrew tap. The cask installs /Applications/RepoPrompt CE.app and consumes a promoted public updater ZIP; it does not build from source.

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

After that you should have RepoPrompt CE.app in /Applications. Open it, add your repositories as roots, and select the files you want in the prompt. The README describes the loop as: pick files and codemaps, configure prompt packaging and Git context, then copy the prompt. Nothing in the README documents a first-run wizard, so expect to configure the workspace yourself.

If you would rather build from source, the repository ships Finder launchers. Double-clicking Launch RepoPrompt CE.command requires Python 3, builds through the coordinated developer daemon, and opens the debug app while keeping a terminal window for rebuild, status and stop controls. The launcher keys are r to rebuild and relaunch, s for status, x to stop, and q to close the launcher without stopping the app. If your Mac has no Apple Development signing identity, the README gives this fallback.

ALLOW_ADHOC_SIGNING=1 ./conductor app relaunch

Ad-hoc debug builds use in-memory secure storage, so API keys and secure permission changes do not persist across launches. For persistent Keychain storage you pass a stable identity instead, for example SIGN_IDENTITY="Apple Development: Your Name (TEAMID)" ./conductor app relaunch. A third path, Install RepoPrompt CE Local Production.command, builds a release-mode app into /Applications with a self-signed certificate trusted only on your Mac; the README states the result is local-only, not notarized, and should not be copied to another Mac or redistributed. For contributors, make xcode generates a disposable workspace, and the README names the RepoPrompt CE App, RepoPrompt CE MCP and RepoPrompt CE Tests schemes.

Where RepoPrompt CE is the wrong tool

The hard constraint is the platform. Source-build requirements are macOS 26 or later, with Xcode 26 or matching Command Line Tools carrying the macOS 26 SDK. The Finder debug launcher and the local production installer require the full Xcode app, not just the command line tools. If your team develops on Linux or Windows, this project does not meet you there, and the MCP server does not change that: the harness is built around a native macOS interface.

The debug path has a second, less obvious cost. The README warns that if you use the debug app to modify RepoPrompt CE itself, validation flows that launch the app or run live smoke checks may rebuild and relaunch it, so expect restarts while those checks run. That is a reasonable property for a project that tests its own launch path and an annoying one if you wanted a stable window.

There is also a signing trap. Without an Apple Development identity, the ad-hoc route stores secrets in memory only, so saved API keys vanish on every relaunch. Anyone evaluating the app casually may read that as a bug rather than a signing configuration.

RepoPrompt CE compared with an editor-integrated assistant

The nearest alternative most readers already have is an editor-integrated assistant: the editor knows the open file, the project root and the language server, and it sends context implicitly. RepoPrompt CE inverts that. It is a separate native app with multi-root workspaces, and the context is assembled explicitly from files, line slices, CodeMaps and Git diffs, then reviewed before it leaves.

The practical difference is who decides what the model sees. In the editor model, the tool decides and you trust it. In RepoPrompt CE, Context Builder curates within a token budget and Context Composer lets you inspect the result. That is more work per prompt and more control over it. It also means the app is the place you work, not a panel inside the place you already work, which is the cost of the approach.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived. The last push was on 2026-08-11, the same day as the v1.3.0 release, following v1.2.0 on 2026-08-03 and v1.1.2 on 2026-07-30. Three releases inside two weeks is a fast cadence, and the README shows the machinery behind it: release-rollout.json, tip-rollout.json, version.env, a release-preflight target, and a docs/open-source-readiness.md that maintainers use to track release signing, Sparkle metadata, dependency pins and third-party notices. There is a THIRD_PARTY_NOTICES.md and a ThirdPartyLicenses directory at the top level.

The project is Apache-2.0, which permits commercial and private use and requires attribution and notice retention; the bundled dependencies carry their own terms, which is what the third-party notices are for. This is a description of the licence text, not legal advice, and if you redistribute the app you should read LICENSE and THIRD_PARTY_NOTICES.md yourself. Upgrading is cheap on the Homebrew path, since the cask consumes a published updater ZIP, and expensive on the source path, where you need the full Xcode toolchain and the release preflight targets to behave.

Editorial conclusion

Adopt RepoPrompt CE if you run CLI-backed coding agents on macOS 26 and want the context they receive to be inspectable before it is sent, and if a signed Homebrew cask is an acceptable install path. Skip it if you work on Linux or Windows, if you want a hosted service, or if you cannot install a full Xcode for the source-build routes. Before committing, verify the exact Homebrew tap commands against the README, confirm your machine meets the macOS 26 and Xcode 26 requirements, and read docs/architecture/context-composer.md, because that document is where the selection invariants behind the prompt you send are defined.

Frequently asked questions

Official sources

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