Getting started

RecallAccelerator (RA) is an AI-first project memory and task tracker. It gives Claude Code, Codex, Cursor, and humans one shared, durable brain across coding sessions and tools.

The core loop:

1. An agent (or you) opens a session in any repo and asks RA "what should I work on for this project?"
2. RA hands back the highest-priority ready task plus the full project context (brief, decisions, prior handoffs, related notes).
3. The agent claims the task atomically (no two agents can pick the same one), does the work, and writes a handoff back to RA.
4. The next session - same agent, different agent, different tool, different machine - starts from a clean slate but with the full audit trail of what was done and why.

Key design rules: brief is versioned (agents propose changes, humans approve via /BriefProposals); every important action lands in the activity log; releases tie completed work to specific deploys; only one agent can hold an active claim on a task at a time.

Registration is gated by an allowlist - your email must be in the Auth:AllowedEmails config before you can register. If you're already on the list:

1. Go to /Identity/Account/Register
2. Enter your email + a password (8+ chars with at least one digit)
3. Log in at /Identity/Account/Login

If you get "Email '...' is not authorized to register on this instance", contact the admin to add your email to the allowlist (env var Auth__AllowedEmails__N on the host panel).

The MCP server is a thin Python wrapper that lets Claude Code, Codex, and any other MCP-aware tool call RA's API. It runs on your local machine; there's nothing to install on the server.

Prereqs: Python 3.11+. (No SQL driver or ODBC needed — the MCP talks to RA over HTTPS only.)

Option A — pip install from GitHub (recommended for most users)

One command, no clone. Use this if you just want to use the MCP:

python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install git+https://github.com/ericboen/Recall_Accelerator_MCP.git

That installs recallaccelerator-mcp.exe at .venv\Scripts\ — the launcher each AI tool will spawn. To upgrade later: pip install --upgrade git+https://github.com/ericboen/Recall_Accelerator_MCP.git.

Option B — clone for editable install (if you'll modify the source)

Use this if you want to hack on the MCP itself. pip install -e means changes to the source take effect on the next launcher invocation — no reinstall needed:

git clone https://github.com/ericboen/Recall_Accelerator_MCP.git
cd Recall_Accelerator_MCP
python -m venv .venv
.\.venv\Scripts\pip install -e .

Either path produces the same launcher binary at .venv\Scripts\recallaccelerator-mcp.exe. The standalone repo is mirrored from the main RA repo's mcp/recallaccelerator-mcp/ folder; file issues / PRs on the main repo unless they're packaging-specific.

Generate an API key first (see section 5 below if you haven't), then in PowerShell:

claude mcp add recallaccelerator --scope user `
  --env RECALLACCELERATOR_TOOL_NAME=claude-code `
  --env RECALLACCELERATOR_API_KEY=ra_paste_your_key_here `
  -- "C:\path\to\recallaccelerator\mcp\recallaccelerator-mcp\.venv\Scripts\recallaccelerator-mcp.exe"

If your claude CLI doesn't accept --env, add the bare server with claude mcp add recallaccelerator --scope user -- "..." and then edit ~/.claude.json to add the env block manually.

Restart Claude Code. Verify with: "Use the recallaccelerator MCP server_info tool" - you should see api_key: (set) and tool_name: claude-code.

Open or create %USERPROFILE%\.codex\config.toml and add:

[mcp_servers.recallaccelerator]
command = "C:\\path\\to\\recallaccelerator\\mcp\\recallaccelerator-mcp\\.venv\\Scripts\\recallaccelerator-mcp.exe"
env = { RECALLACCELERATOR_API_URL = "https://recallaccelerator.offcamber.ai", RECALLACCELERATOR_AGENT_NAME = "Your Name", RECALLACCELERATOR_TOOL_NAME = "codex", RECALLACCELERATOR_API_KEY = "ra_paste_your_codex_key_here" }

Note the doubled backslashes in the path - TOML treats \ as an escape character. Restart Codex; verify the same way ("call server_info").

Use a separate API key per tool ("Claude Code on NIKXDOG" vs "Codex on NIKXDOG") so revoking one doesn't kill the other and the activity log shows which tool made each call.

Go to /ApiKeys (login required), enter a descriptive name like "Claude Code on <machine>", click Generate key. The plaintext ra_... value is shown once - copy it before navigating away.

Paste the key into the corresponding tool's MCP env block (see sections 3 and 4). The X-Api-Key header is sent on every /api/* request once Auth__RequireApiKey=true is set on the host.

If you ever lose a key or want to retire one, hit Revoke on /ApiKeys; the agent using it stops working immediately. Generate a new one and update the tool's env block.

Drop the CLAUDE.md and AGENTS.md templates into your home directory so every Claude Code / Codex session in any folder knows the RA ritual without per-project setup. From your cloned repo root:

$repo = "C:\path\to\recallaccelerator"
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.claude" | Out-Null
Copy-Item "$repo\docs\templates\CLAUDE.md" "$env:USERPROFILE\.claude\CLAUDE.md" -Force
Copy-Item "$repo\docs\templates\AGENTS.md" "$env:USERPROFILE\AGENTS.md" -Force
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.codex" | Out-Null
Copy-Item "$repo\docs\templates\AGENTS.md" "$env:USERPROFILE\.codex\AGENTS.md" -Force

The templates encode the start-of-session ritual, the "slug = lowercase folder name" convention, and the hard rules (never overwrite a brief, don't claim human_only tasks, heartbeat every 20 min on long work). Edit the templates in the repo and re-run the install snippet to update.

Source files: docs/templates/CLAUDE.md, docs/templates/AGENTS.md, docs/templates/README.md (full install guide).

The user-level templates from step 6 cover every repo. The per-repo file pins down this repo's RA project — slug, project_id, instance URL, repo URL — so a fresh agent in a new clone doesn't have to guess.

Path A — let the agent fetch it (recommended)

If your repo already has an RA project, just ask the LLM:

"Get the per-repo agent files for this project."

The agent calls get_project_agent_files(project_id), gets back ready-to-paste contents for all three files (CLAUDE.md, AGENTS.md, .cursorrules), and shows them to you. Drop the one(s) matching your tool at the repo root. Multiple is fine — they're equivalent.

If the repo doesn't have an RA project yet, ask:

"Create a new RA project for this repo."

The agent calls create_project(...), which now embeds the same agent files in the response. Same drop-at-the-root flow.

Path B — copy by hand

If you'd rather not use the LLM for this, the templates are in the repo at docs/templates/per-project/. Copy the one matching your tool to the repo root and replace the {{SLUG}} / {{PROJECT_ID}} / {{PROJECT_NAME}} / {{INSTANCE_URL}} / {{REPO_URL}} placeholders with values from /Projects:

Copy-Item "$repo\docs\templates\per-project\CLAUDE.md.template" .\CLAUDE.md
# then edit the {{...}} placeholders

Which file for which tool?

• CLAUDE.md at repo root — Claude Code reads this automatically.
• AGENTS.md at repo root — Codex (and any AGENTS.md-aware tool) reads this.
• .cursorrules at repo root — Cursor's classic-format rules. For the newer .cursor/rules/*.mdc format, rename and add a frontmatter block.

All three files are self-contained — they restate the start-of-session ritual, in-flight writebacks, hard rules, and end-of-task ritual so even a cold agent without the user-level templates installed has everything it needs.

Try it end-to-end (the cold-onboarding test)

Best way to confirm onboarding works for a new user is to simulate one from a fresh repo:

1. Make a throwaway repo on disk:

   mkdir C:\path\to\test-onboarding
   cd C:\path\to\test-onboarding
   git init
   "# test" | Out-File README.md
   # DO NOT add a CLAUDE.md/AGENTS.md yet — that's the point

2. Open Claude Code (or Codex/Cursor) in that folder. No agent file exists, so the agent has no breadcrumb to RA.
3. Tell the agent: "Use the recallaccelerator MCP and start the session ritual." The agent should call list_projects, find no matching slug, then ASK before creating one. (Per the user-level CLAUDE.md hard rules — never auto-create.)
4. Confirm when it asks. The agent calls create_project(...); the response embeds three pre-filled files (CLAUDE.md / AGENTS.md / .cursorrules). The agent shows them to you and tells you which matches your tool.
5. Drop the matching file at the test repo's root.
6. Quit and reopen the LLM tool in the same folder. Brand-new session, no memory of step 4.
7. Ask: "What should I work on?" Now the agent reads the per-repo file, sees the project_id, and runs get_project_brief → list_ready_tasks → claim_next_task against the right project. Cold-start works.
8. Clean up. Visit /Projects/Detail?id=N for the test project → Lifecycle → Archive, then expand the delete sub-collapsible, type the slug, and Delete forever. Or use the /Archive page for the same flow cross-project.

If the generated files contain the literal string recallaccelerator.example.com instead of your real instance host, the instance-URL fallback isn't working. Set Instance__PublicUrl=https://your-host as an env var as a workaround, and file a bug — the service should auto-derive the URL from the inbound request.

Open Claude Code or Codex in a repo folder. Ask the agent: "Use the recallaccelerator MCP and start the session ritual." The agent will:

1. list_projects and find the one whose slug matches the folder name
2. get_project_brief(project_id) to read scope, goal, and warnings
3. list_ready_tasks(project_id) to see what's claimable
4. claim_next_task(project_id) to atomically grab the highest-priority task
5. Do the work in your repo
6. complete_task with a real handoff (summary, files changed, follow-ups, optional release_id)

If the project doesn't exist in RA yet, the agent asks you before bootstrapping it via create_project, create_brief_version, and create_task.

Pending Proposals (the "we should also..." bucket)

While the agent is working it will often spot follow-up work that you didn't ask for. Instead of dumping it straight into the ready queue (where it competes with everything you actually prioritized), the agent calls propose_task(project_id, title, context, suggested_priority) — that drops a half-formed suggestion into the Pending Proposals bucket. Triage them at /Proposals: accept turns the proposal into a real ready Task; reject discards it with an optional note. The point is to capture every "we should also..." moment without breaking your concentration mid-session.

While you're in the chat, browse the dashboard, Projects, Proposals, Activity, and Releases to see what's happening across all your projects in real time.

If you're running your own RA instance (not just using recallaccelerator.offcamber.ai), two PowerShell scripts under db/ handle the heavy lifting:

db/apply-aspnix.ps1 - schema migrations

Reads each db/migrations/00N_*.sql file, strips the USE statement, substitutes cxctestc_offcamber. for the target schema name, and applies via Microsoft.Data.SqlClient one batch at a time (split on GO).

$cfg = Get-Content $env:APPDATA\RecallAccelerator\config.json | ConvertFrom-Json
.\db\apply-aspnix.ps1 `
  -ConnectionString $cfg.ConnectionStrings.RecallAcceleratorDb_Aspnix `
  -Schema "cxctestc_recallaccelerator" `
  -Migrations 1,2,3,4,5,6 `
  -ReleaseId 7 `
  -DryRun

Drop -DryRun to actually apply. Pass -ReleaseId N to tie the deploy to a Release record.

db/publish-aspnix.ps1 - FTP publish

Builds via dotnet publish, drops app_offline.htm to release IIS file locks, mirrors the publish folder via FTPS with per-file retries, removes app_offline.htm. Skips appsettings*.json by default (override with -IncludeAppsettings).

As of v0.8.0 the script reads FTP credentials from env vars set by racred run — no more config.json path, no more $env:RECALLACCELERATOR_FTP_PASSWORD dance. The canonical invocation:

racred run -- pwsh .\db\publish-aspnix.ps1 -ReleaseId 12

Prereq: five creds in /Credentials (all category=ftp):

aspnix_ftp_host         e.g. ftp.aspnix.com
aspnix_ftp_port         optional, defaults to 21
aspnix_ftp_user         the FTP account name
aspnix_ftp_password     the actual secret
aspnix_ftp_remote_path  the remote dir to mirror into (e.g. /wwwroot or blank)

racred fetches the values, injects them as $env:ASPNIX_FTP_HOST etc., then execs the script. After upload, recycle the app pool on your hosting panel.

Run the script without racred run -- and it bails fast with a clear hint — no silent fall-through to a half-configured deploy.

RA stores secrets so your AI agents can use them without ever seeing the cleartext. The MCP exposes only names ("you have a github_token"); the racred CLI is the only path that returns values, and it injects them directly into a child process's environment instead of into the chat. A compromised or prompt-injected LLM session can't exfiltrate what it can't read.

10a. Add credentials at /Credentials

Pick a name (lowercase recommended, e.g. github_token), paste the value, choose a scope:

• Global — visible to every project (your personal GitHub PAT, OpenAI API key, etc.)
• Project-scoped — visible only when the agent is working in that project's repo (DB password for one app, FTP creds for one host, etc.)

Project-scoped wins over global when names collide — handy for "default OpenAI key everywhere except this one project that uses a team account." Categories (cloud / database / api / ftp / oauth / misc / anything you invent) are organizational hints for the admin UI; they don't affect routing.

10b. Install racred on the agent box

The CLI ships in the same package as the MCP (section 2 above). If you've already installed the MCP, you have racred too:

.\.venv\Scripts\racred --help

If you skipped the MCP install, the install command is the same:

pip install git+https://github.com/ericboen/Recall_Accelerator_MCP.git

The CLI uses the same RECALLACCELERATOR_API_URL + RECALLACCELERATOR_API_KEY env vars the MCP already reads. Set them once at the user level and both work.

10c. Day-to-day usage

Run from inside a repo whose folder name matches your project's slug. The CLI auto-detects which project you're in (same way the MCP does) and pulls only that project's creds + globals.

# See what's available right now
racred list

# Print one value (newline-terminated, suitable for $(racred get FOO) substitution)
racred get github_token

# Inject ALL visible creds into a child process's env, then exec it
racred run -- gh repo list
racred run -- aws s3 ls
racred run -- psql

# Diagnose project resolution + API config
racred whoami

The most common pattern: tell the agent "use racred to run gh repo list." The agent shells out via its bash tool, the value lands in gh's environment, the chat session never sees it. Each fetch lands in the audit log at /Credentials with the command, project, agent — no values, no full argv (which could leak secrets passed as flags).

10d. End-to-end example: deploying RA itself

The canonical "first real use case" for the broker is shipping RA. Walks through every concept in one workflow:

1. Add five creds at /Credentials (all category=ftp, scope=recallaccelerator):

   aspnix_ftp_host          → ASPNIX_FTP_HOST          ftp.aspnix.com
   aspnix_ftp_port          → ASPNIX_FTP_PORT          21
   aspnix_ftp_user          → ASPNIX_FTP_USER          cxctestc_offcamber
   aspnix_ftp_password      → ASPNIX_FTP_PASSWORD      *********
   aspnix_ftp_remote_path   → ASPNIX_FTP_REMOTE_PATH   /

   Env var field stays blank for all five — auto-uppercase of the name is exactly what the script reads.
2. Add the SQL connection string (category=database, scope=recallaccelerator). Env var override = ConnectionStrings__RecallAcceleratorDb_Aspnix (the __ trick maps it into IConfiguration["ConnectionStrings:RecallAcceleratorDb_Aspnix"]).
3. Create the release at /Releases (or via MCP create_release). You get a release id back, e.g. 12.
4. From the repo root:

   racred run -- pwsh .\db\publish-aspnix.ps1 -ReleaseId 12

   racred resolves the project from CWD, fetches every visible cred, sets their env vars, then execs the script. The script reads $env:ASPNIX_FTP_* and runs the FTP publish. Release transitions through start → complete automatically via -ReleaseId.
5. Audit: open /Credentials — the "Recent fetch activity" panel shows five rows tagged pwsh as the command basename, all for the right project, with success status.
6. Recycle the app pool on the ASPNIX panel.

The broker turns "did you remember to set RECALLACCELERATOR_FTP_PASSWORD this session?" into "the broker has it; just run racred." Once one workflow is wired this way, the pattern composes — every script you write from here on follows the same shape.

10e. What NOT to store in the broker

The mental model: broker things the LLM chat session would otherwise see. Don't broker the scaffolding that's needed to reach the broker in the first place, or values that have to live at the shell / user-env level for other tooling to work.

Skip these:

• RECALLACCELERATOR_API_KEY — already lives in your MCP launcher env block (claude.json, codex config.toml, etc.) and in your user env where racred itself reads it. Brokering creates a circular "broker auth via broker" dependency that drifts on every key rotation. Found this the hard way during the v0.8.0 bootstrap — the deploy script's release-tracking calls 401'd because the broker had a stale value overwriting the live one in the parent shell.
• RECALLACCELERATOR_API_URL — same logic. Lives in launcher env. Non-secret config.
• Other shell scaffolding — PATH, USERPROFILE, JAVA_HOME, etc. Obvious in retrospect; worth saying.
• Keys consumed only by the deployed app process — e.g. Anthropic__ApiKey read by the API from IConfiguration at startup. The broker injects env vars into local processes spawned via racred run; it can't push env vars to the ASPNIX IIS app pool. Those values belong in the host's panel (or your local user env / dotnet user-secrets for dev), not duplicated in the broker. Brokering them creates a second source of truth that drifts on rotation — same trap as RECALLACCELERATOR_API_KEY above. (Bit us during v0.9.0 — task #38.)

Do broker these:

• FTP / SFTP credentials for hosting providers (consumed by publish-aspnix.ps1 via racred run)
• Database connection strings if a local script needs them (the deployed app reads its DB string from the host panel, not the broker)
• Third-party API keys that scripts or CLI tools call from your machine — GITHUB_TOKEN for gh, STRIPE_API_KEY for a billing script, OPENAI_API_KEY for a local one-shot, etc.
• OAuth client secrets, signing keys, any cleartext the agent might want to inject into a tool call but should never see

Rule of thumb: ask "who reads this value, and where?" If a local CLI tool or script reads it (racred run -- gh ...), broker it. If only the deployed server process reads it from its own IConfiguration on the host, set it on the host panel — the broker can't reach there anyway.

Quick test for "should I broker this?": would the chat session need this value as a literal string in a prompt or response? If yes, broker it (so it can flow through env-var injection instead). If no — if it's just config that has to be set at process-launch time for the broker itself to work — leave it in the launcher's env block.

10f. Operational rules

• Outside any repo the CLI fails loud — it won't silently fall back to globals if you forgot to cd. Use --project SLUG to override explicitly when you really mean it.
• Disable instead of delete to retire a cred — fetches return 410 Gone immediately, audit history stays intact for "who fetched this last week" queries. Hard delete works too, but the audit row's CredentialId becomes orphaned (the name is preserved).
• Rotate by editing the cred and pasting a new value. The ciphertext changes; old value is unrecoverable. (Versioned rotation is a future scope-2 enhancement.)
• Never commit secrets to git, paste them into a chat, or share them across users. The whole point of this tool is making "the right thing" the easy thing.

RA is most powerful when you stop typing tool names and start typing intent. Each row below is a copy-paste prompt that maps to one or more MCP tool calls. Drop these into Claude Code / Codex / Cursor verbatim — the agent will translate.

Daily workflow

Say this	Agent does
Start the session ritual.	list_projects → get_project_brief → list_ready_tasks → claim_next_task
What's in my queue for this project?	list_ready_tasks(project_id) — no claim, just a preview
What changed recently?	get_project_activity(project_id, limit=20)
Mark this task done.	complete_task with a handoff (summary, files changed, follow-ups)
I can't finish this — release it.	release_task(task_id, reason)
Heartbeat my session.	heartbeat_session(session_id) — extends the lease so you don't lose the claim

Capturing work mid-session

Propose a follow-up: <title>.	propose_task(...) — lands in /Triage for review, doesn't pollute the ready queue
Add a context note: <...>	add_context_note(project_id, content, note_type) — warnings, gotchas, "be careful here"
Record this decision: <...>	add_decision(project_id, title, decision_text, reason, impact) — architectural choices that future agents need
The brief is out of date — propose an update.	propose_brief_update(...) — lands at /Triage. Agents never overwrite the brief directly.

Project setup & agent files

Bootstrap a project for this repo.	If list_projects finds no slug match: drafts compact_description/goal → asks before creating → create_project + create_brief_version + initial tasks
Get the per-repo agent files for this project.	get_project_agent_files(project_id) — returns ready-to-drop CLAUDE.md / AGENTS.md / .cursorrules with placeholders pre-filled
Capture this as a future-idea project.	create_idea(...) — parking lot at /Ideas, doesn't clutter the dashboard until you promote it

Credentials & deploy

What credentials do I have for this project?	list_credentials(project_id) — names only, never values
Does the <name> credential exist?	describe_credential(project_id, name) — checks scope, env-var mapping, disabled status
Run <command> using stored credentials.	Agent shells out via bash: racred run -- <command>. Values flow into the child process's env, never into chat.
Set up credentials for deploying this project.	Agent calls list_credentials, sees what's missing, walks you through adding via /Credentials

Releases

Create a release for <version>.	create_release(project_id, version, release_notes)
Attach the work I just did to release <N>.	attach_to_release(release_id, item_type, target_id) for tasks / features / decisions
Mark release <N> shipped.	start_release → complete_release (also auto-creates a brief-update proposal)
Show me the changelog for release <N>.	get_release_changelog(release_id)

The full MCP tool reference is in /swagger (look at the controllers — every endpoint has an MCP wrapper). The prompts above are just the common shapes; the agent will improvise from any natural-language request that maps clearly to one of these tools.

All key management happens at /ApiKeys (login required):

• Create: name + Generate → plaintext shown ONCE → paste into the tool's MCP env block
• Inspect: see name, prefix, created date, last-used timestamp, status
• Revoke: hit the button. The agent using that key gets 401 on the next request.

Best practices: one key per (tool x machine) combination so audit/revocation is granular. Rotate periodically. Never commit keys to git.

RA can send email for two separate purposes. They live in different places — don't conflate them.

13a. RA's own outbound email (this site)

Consumers: ASP.NET Identity password-reset flow + the NotifierService daily digest (pending proposals, pending brief updates, pending session reconciliations, stale claims, releases in the last 24h). Future alerts will hang off the same IEmailSender.

Configured via env vars on the ASPNIX hosting control panel for the API app pool — NOT the cred broker. The broker can only inject env vars into local processes spawned via racred run; the deployed IIS process reads its config from the host panel at boot. Same lesson as Anthropic__ApiKey from v0.11.0 (and Decision #29 / Help 10e).

Two transports, pick one with Email__Provider:

• resend — HTTPS to api.resend.com on port 443. Use this when the deployed host blocks outbound SMTP (the situation on ASPNIX — see task #90 for the debug session that drove this design). Recommended.
• smtp (default) — System.Net.Mail.SmtpClient over your configured SMTP server. Works on hosts that allow outbound 25/465/587.

Required env vars — Resend (recommended)

• Email__Enabled=true
• Email__Provider=resend
• Email__ResendApiKey=re_... (from resend.com/api-keys)
• Email__From=noreply@send.offcamber.ai (must match a domain verified in your Resend dashboard)

Sender-domain alignment for offcamber.ai: the DNS is set up for the send.offcamber.ai subdomain (apex stays anaxanet-only via the existing v=spf1 include:_spf.anaxanet.com -all). Configure Resend's dashboard for the send subdomain — the DKIM record at resend._domainkey, SPF at send TXT, and bounce MX at send MX feedback-smtp.us-east-1.amazonses.com are already in place.

Required env vars — SMTP (legacy)

• Email__Enabled=true
• Email__Provider=smtp (or unset; smtp is the default)
• Email__Host=mail.offcamber.ai
• Email__Port=587
• Email__Username=admin@offcamber.ai
• Email__Password=<smtp password>
• Email__From=admin@offcamber.ai
• Email__UseStartTls=true

Optional (both providers)

• Email__FromDisplay=RecallAccelerator (default)
• Email__DigestHourUtc=8 (default; 0-23)

Disable cleanly by setting Email__Enabled=false (or leaving it unset). When disabled, NoOpEmailSender takes over — Identity password-reset and digest calls still succeed at the DI level, they just log "would have sent" instead of opening a socket.

Recipients of the daily digest = every address in Auth__AllowedEmails__N. No per-user opt-out yet (v1).

Smoke after enabling: hit POST /api/diagnostics/email-smoke?to=<your-email> with an X-Api-Key header. The response echoes the effective Email:* config (password redacted to a boolean) and points at the Serilog file for the actual delivery outcome (Email sent via Resend. / Email sent. on success, or a Warning with the exception/HTTP status inline). Faster than running through password-reset since it bypasses Identity's anti-enumeration redirect.

13b. SMTP creds for other projects you track here

Different scenario: you're working in a project (SHE Leads, She Shares, an Intro Tool repo) whose code needs SMTP to send its own emails. RA itself doesn't run that code — it just stores the creds so an agent or local script can fetch them.

This DOES go in the broker, scoped to the specific project. Name them whatever you like — the EnvVar override is what matters because it has to match the target app's config shape. Examples:

• Project "SHE Leads": smtp_host → $SmtpSettings__Host
• Project "SHE Leads": smtp_password → $SmtpSettings__Password
• Project "She Shares" (different stack): mailgun_api_key → $MAILGUN_API_KEY

Agents working in those projects see them via list_credentials(project_id) and inject by telling the user to run racred run -- <app-or-script>. Project-scoped, so creds named the same in two different projects don't collide.

Quick mnemonic: who reads it? The RA prod process → panel. A local CLI/agent script → broker.

If you're logged in, head to the dashboard to see the projects you have access to. If you're new and just registered, ask your AI agent to bootstrap a project record for the repo you're currently working in - it can do the whole thing via the MCP.

Source: github.com/ericboen/RecallAccelerator