Keep related repositories connected.

Connect repositories in the web workspace

1. Sign in and choose Connect GitHub. Complete authorization using the same PersistMemory account that started it.
2. Install the GitHub App on the account or organization you choose. Select the repositories it may access.
3. Create a coding project, load your installations and select a repository you can write to.
4. Choose a tracking branch and a PR target branch explicitly. They can be different. Save the selection for each related repository.
5. Use the project page to inspect the repository state. Reconnect a repository to change either branch; disconnect it to remove its active access.

Each project supports up to ten repositories. A Space association organizes context; it does not grant collaborators access to private GitHub code. GitHub access is checked for the acting account.

When repository analysis changes

Only events for a connected tracking branch request a refresh. The service reads that branch’s current head before analysis, so an older or duplicated webhook cannot move the project backward. A changed commit does not imply that every file must be read or analyzed again.

The project records the desired commit and the indexed commit separately. Until analysis catches up, the web page shows that distinction. Branch deletion, access revocation or a removed installation makes the repository unavailable. Background reconciliation also checks for changes when a webhook is missed.

Connect API documentation changes

Use API change watches to save official documentation and check for updates. Our crawler performs a fresh check, uses conditional HTTP requests when possible, and keeps the previous baseline if the page is blocked or unavailable. Review the source change alongside affected code.

Reading a public URL uses the built-in crawler. JavaScript pages can use the separately configured isolated browser. TinyFish and Firecrawl are optional search providers; they are not required for GitHub connections or direct page reads.

1. Create a documentation watch and choose manual or daily checks. Enable email alerts on the watch when you want notifications.
2. Open your coding project and use API change alerts and repairs to link that watch to the repositories that consume the API.
3. Choose tracking only, or enable automatic repair and draft PRs. Automatic repair also requires test commands and automatic draft publication on every selected repository.
4. Review classified source changes and queued runs in the project. Pausing or removing the policy fences work that has not yet been authorized under the current policy.

Repeated checks of the same accepted/pending hashes produce one email intent. Alerts obey account email preferences and quiet hours; accepted, reverted, deleted or disabled evidence is checked again before delivery. A documentation edit alone does not prove your code needs a repair.

Run features and repairs across repositories

In the project’s Coding runs section, configure setup and test commands for each repository. Select the repositories involved, describe the feature or repair, and choose finite sandbox and model-call limits. A coordinator plans the work, up to two repository agents implement changes, and a separate reviewer checks the resulting artifacts and evidence.

Baseline and patched tests run in separate fresh E2B workspaces. Each contains all selected repositories at /workspace/repos/<owner>/<repo>. Commands start in their own repository; PM_WORKSPACE_ROOT identifies the common workspace. Configure integration or contract tests to exercise related repositories together.

A run permits at most one repair attempt. Defaults are 300 reserved sandbox seconds and eight model calls, with a maximum of five repositories, 900 seconds and 20 calls. Model requests also use your account’s spending controls. Reserved sandbox seconds are a conservative execution allowance, separate from provider-reported runtime.

Inspect changed files, check output, reviewer risks and recorded commits before publishing. Draft PRs use the chosen target branches and are never automatically merged. Stop revokes the run’s worker lease and retains cleanup obligations. Steer starts a new continuation with fresh limits, preserving the earlier artifacts in history.

Use Claude, Codex, Cursor or chat

Connect your preferred client to the PersistMemory MCP server. The same account’s coding projects, graph and runs are available from MCP, web chat and connected Telegram or WhatsApp conversations. The client requests work through shared tools; the hosted worker coordinates execution.

List my coding projects.
Check the latest documentation for my saved API watch.
Add pagination to the selected backend and web repositories.
Show the run's changes and test results.
Stop this coding run.

Project and run reads are read-only tools. Starting work, changing a hosted watch, steering, stopping and publishing use the client’s permission or confirmation flow and your authenticated identity. An ambiguous project or repository requires a selection. Private project tools are unavailable in group-chat contexts.

Operator setup

Create a GitHub App and configure its user authorization callback to your web host’s /dashboard/coding/github/callback. Point its webhook at your API host’s /webhooks/github/coding. Subscribe to push and installation events, including changes to the installation’s repository selection.

Create a GitHub App with Contents and Pull requests read/write permissions and Metadata read-only access. Analysis uses a narrower read token; draft publication uses a separate write token. Other permissions are unnecessary. Choose Any account for a customer-facing App, keep expiring user tokens enabled, and leave authorization during installation disabled: Connect GitHub starts the account-bound authorization flow. Set the installation Setup URL to your web host’s /dashboard/coding.

Copy the App ID, slug and Client ID, generate a Client Secret, and generate its PEM private key. Legacy GITHUB_CLIENT_ID OAuth App credentials cannot replace the GitHub App’s installation and signing configuration. The acting user must have repository write access; installation alone never grants project access.

GITHUB_APP_ID=
GITHUB_APP_SLUG=
GITHUB_APP_PRIVATE_KEY=
GITHUB_APP_CLIENT_ID=
GITHUB_APP_CLIENT_SECRET=
GITHUB_APP_WEBHOOK_SECRET=
GITHUB_APP_STATE_SECRET=
GITHUB_APP_OAUTH_REDIRECT_URI=https://your-web-host/dashboard/coding/github/callback

# Existing encrypted integration storage configuration
INTEGRATION_ENCRYPTION_KEYS=
INTEGRATION_ENCRYPTION_ACTIVE_KEY=

Keep these values in trusted API and worker configuration. The state secret must be at least 32 characters and the webhook secret at least 16. Use the existing encryption key format documented for integrations; do not replace working keys when adding GitHub. Run the database migrations before starting the services.

E2B_API_KEY=
E2B_CODING_TEMPLATE=base
# API webhook authentication; generate a separate random secret
E2B_LIFECYCLE_WEBHOOK_SECRET=
# Optional: constrain accepted provider identities after registration
E2B_LIFECYCLE_WEBHOOK_ID=
E2B_TEAM_ID=

Repository code and tests run only through E2B. The explicit base template supports Node, Python and bash; other runtimes need a suitable template. Dependency installation is restricted to configured public registry domains. GitHub, model and application credentials stay in the trusted services and are not copied into guests.

Sandbox activity and operator monitoring

E2B lifecycle deliveries go to your API host’s /webhooks/e2b/lifecycle. Deploy the handler and migration before registering that endpoint. The registration helper checks readiness and matching signing configuration, then creates or updates the named provider webhook and writes a receipt.

node --import tsx scripts/setup-e2b-webhook.mts \
  --env .env.production \
  --url https://api.persistmemory.com/webhooks/e2b/lifecycle \
  --apply --receipt /tmp/e2b-webhook-receipt.json

Authenticated, deduplicated lifecycle events are linked using independently registered sandbox IDs, including events arriving before the SDK’s create response. Missed deliveries can be reconciled through the provider’s event API. The run page displays activity separately from check results: a stopped sandbox does not prove tests passed.

Admin → Coding & crawler shows configuration, browser reachability, graph/run queues, reserved usage, lifecycle delivery and pending cleanup. Operators can stop a run with a recorded reason. This console excludes repository source, prompts and patches.

If something is unavailable

• Setup required: finish the operator configuration and restart the API and worker.
• No installation or repository: check the App’s selected repositories, your organization’s authorization policy and your current GitHub permissions.
• Authorization expired: start a new connection. Each callback state belongs to one account, expires after ten minutes and can only be consumed once.
• Project changed: refresh the project before changing its branches or repositories. Writes use the project version to protect newer selections.
• Website verification: a Cloudflare or other verification screen is reported as a blocked read. It cannot become an API documentation baseline.