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. Choose Connect repository, select your GitHub account or organization’s installation, and choose a repository you can write to. No project needs to exist first.
4. Choose a tracking branch and a PR target branch explicitly. They can be different. Optionally expand Group with other repositories and choose an existing project; otherwise one is created for this repository.
5. Connect the repository. Its saved card shows both branches even when no coding run is active. Use Edit branches to change either selection, or Open workspace to inspect the graph, configure checks and start work.

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.

Follow work from one overview

The coding workspace keeps all saved repository connections visible between runs. Repository and activity lists have independent pages with shown and total counts. Filter recent work into active runs, review or failed items, and recorded pull requests. A run link opens that exact run in its project.

Saved branch and commit information includes the last access-check time; opening the overview does not reanalyze every repository. A recorded PR link proves publication was recorded, but does not claim the PR is still open or a draft. Open GitHub to check whether it has been merged or closed. Needs attention includes historical failed and expired runs as well as runs awaiting review.

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.

Understand the repair evidence

Add optional reproduction commands to your repository test configuration. Each command should assert the affected behavior, exit 1 when that assertion fails, and exit 0 when it passes. The same commands run on the pinned baseline and patched source, alongside healthy setup and regression checks.

Verified reproduction means those configured checks failed on the baseline and passed on the patch. Checks passed means regression checks passed without a reproducer. Unconfirmed means the evidence is missing, incomplete, inconsistent or does not reproduce the problem. Review the command output and proposed tests; these results do not guarantee production behavior.

The run also shows supported package and API relationships between the selected repositories, with their source files and commits. Dynamic addresses, unsupported formats and incomplete analysis remain visible uncertainties. Related repositories share the test workspace; configure integration tests to exercise them together.

Teach future investigations from your review

After a run stops or reaches review, record an accepted approach, rejected approach or compatibility constraint for a repository. Explain why. Future runs on the same project, repository and branches receive that reviewed decision and retain its source run and version.

You can edit or archive these decisions. They remain private to your account and selected repository scope. Accepting an approach records your feedback; it does not merge code, approve a draft PR or prove the repair works in production.

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.

Switch topics without mixing memories

You can discuss a trip, ask for a code fix, and return to the trip in one conversation. Ask shows a topic label on each message. Coding uses its own Space and selected repositories, so its history and saved memories stay separate from your trip.

Choose repositories above the composer, or ask for the code work directly. If the destination is unclear, choose a project and its repositories before sending the message. Use a topic button or say “Back to Trip” to continue its earlier discussion. The Coding page shows the saved work and PR target branches.

Connected private chat channels use the same topic boundaries. Say use repo owner/name to choose a connected repository or Back to Trip, plan tomorrow to return to a named topic. MCP clients can select topics and read their separate histories; the external AI app controls its own visible transcript and must send contextTopicId for concurrent chats. Returning to a conversation checks access again. A disconnected coding topic does not prevent you from continuing an available personal topic.

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. It also shows saved repository branches, older active runs, recorded PR receipts, watch repair policies and conversation-topic counts by channel. Metadata lists show their bounds and totals. Operators can stop a run with a recorded reason. Current GitHub PR state and topic access are not inferred from these records; repository source, private chat text, prompts and patches are excluded.

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.