Capybara Camp

Your Camp for big ideas

A native Mac app for your Codex and Claude Code sessions. Find a conversation, put it on a Kanban board, and pick it up in chat.

Get started · Download v1.5.0 · Release notes

Release status

v1.5.0 is the current release. It is a universal macOS build, ad-hoc signed and not notarized by Apple. Every local feature works without a Camp account. The hosted Camp server at https://api.capybaracamp.com is in an invite-only pilot, so sharing needs an invitation or your own server. Cloud execution needs a self-hosted server with isolated runners and has not passed live acceptance. The V1 delivery status records what is implemented, tested and still required for a notarized release; the release epic defines the full scope.

Local sessions

• Import accessible local Codex and Claude Code profiles, with their sessions kept separate
• Switch between Board and Chat; search by session, project or profile
• Track live Claude Code activity and inspect saved subagent transcripts
• Resume conversations through the installed provider CLI and its existing login
• Stream Camp-started replies, steer a running turn, and queue prompts
• See each session's own model, effort, speed and Ultracode mode on its card, and choose the model, effort and supported speed for the next reply
• See new, renamed and archived sessions as Codex and Claude save them, and follow open transcripts as the CLI writes them (live session feed)
• Run Codex against Venice AI, OpenRouter, Hugging Face or a custom OpenAI-compatible endpoint, each as its own profile (model providers)

Camp-started sessions begin in chat preview mode, with tools, hooks and MCP servers off. Session permissions turn on project tools for a session after an explicit choice, and an approved plan runs its implementation with the permissions you approve. A session owned by another app must be released there before Camp can send into it. External terminal conversations update when their CLI saves text; Camp cannot display tokens that the CLI has not written or exposed through its activity interface.

Requirements

• macOS 14 or newer, on Apple silicon or Intel
• Codex CLI and/or Claude Code, installed and signed in
• Xcode Command Line Tools for building from source (xcode-select --install)
• Go 1.26.10 or newer for building from source

Provider subscriptions, login and model availability remain with the provider. You only need the CLI for the provider you want to use. Model provider profiles need Codex CLI 0.163 or later and an API key from the provider.

Install

Download Capybara-Camp-1.5.0-macos-universal.zip and SHA256SUMS from the v1.5.0 release. In the download folder, check the ZIP with shasum -a 256 -c SHA256SUMS --ignore-missing, then extract it and move Capybara Camp.app to Applications. One app runs on Apple silicon and Intel. It bundles its Go helper and does not need Python.

v1.5.0 is ad-hoc signed and is not notarized by Apple, so macOS blocks the first open of a downloaded copy. Try to open it once, then choose Open Anyway in System Settings → Privacy & Security. You can instead clear the download quarantine in Terminal, but only for a copy whose checksum matched:

xattr -dr com.apple.quarantine "/Applications/Capybara Camp.app"

Apple's instructions for opening an app from an unidentified developer cover the same steps. Camp does not change Gatekeeper settings. To avoid the download altogether, build from source below.

Build from source

Install the requirements above, then:

git clone https://github.com/teslashibe/capybara-camp.git
cd capybara-camp
./build.sh
open "build/Capybara Camp.app"

This builds the checked-out source for your Mac's architecture. Go is needed on the build machine only; the app includes its local helper. For both Apple silicon and Intel, use ./build.sh --universal.

To build exactly what v1.5.0 shipped, run git checkout v1.5.0 before building. The default branch can move ahead of the latest release.

The seven-step onboarding flow discovers local profiles, then offers optional Camp sign-in, cloud provider accounts, GitHub, a project and Local/Cloud defaults, followed by notifications. Each optional step can be skipped. Finish later saves your place; Capybara Camp → Set up Capybara Camp reopens setup.

Profile discovery does not require choosing folders. Use Manage sources to add an unusual CODEX_HOME or CLAUDE_CONFIG_DIR location if needed. A profile folder can contain several historical account identities; it does not prove that each of those accounts is currently signed in.

Working in the app

Board and chat

Click anywhere on a card to open it, or Tab to it and press Space or Return. The model menu, the ··· menu and the buttons along the bottom still work on their own. Right-click a card for the same actions as its ··· menu. Drag a card to Ready or Done to move it. In progress and Needs you follow the session, and a card can't move while a turn runs; a column that won't take a card says why. Once Camp has seen a session's subagents, its card shows the count, such as 3 subagents, and clicking it opens the chat on that list.

Send with Command-Return. During a local Camp reply, Command-Return steers it and Command-Shift-Return queues the next prompt. Local queues stay paused after a restart until you resume them.

New, renamed and archived sessions appear as Codex and Claude save them, usually within a fraction of a second; the first read of a large library takes longer. Open transcripts use filesystem notifications. Chats open at the bottom and follow incoming output. The main chat and its sub-agents appear above the ten most recent sessions; use @ to find older context. A saved sub-agent transcript alone is not evidence that it is currently running.

Cards show the settings each session runs with: the provider's reported values while a turn runs, otherwise the values Camp last read from the session, such as "Max effort · Fast" or "Ultracode · Extra high effort" ("No reasoning" for a model's none level). Camp leaves out settings it could not read and does not show Standard speed; an unknown model reads "Model not recorded" in muted text.

Model, effort and supported speed controls apply to the next Camp turn. An untouched control keeps the session's own setting and names it, for example "Session · Max"; its menu entry reads "Same as session · Max". Camp only sends the settings you pick, except that a Claude reply names the session's last effort, and Fast when the session last ran Fast, because Claude Code resumes at its settings default. Camp replies do not use Ultracode. In the chat header, they form a compact group; click anywhere inside a field to open its menu. At narrow window sizes the group moves below the chat title so the controls remain readable. Running activity uses settings reported by the provider when available. An external session remains under its original client's control. The native chat editor accepts macOS Dictation as live text.

Plans and projects

Plan uses one model. Plan with comparison uses two independent drafts, one review from each provider and a combined plan. Choose profiles and model settings for the planners, attach session context with @, and keep the planning card running in the background. Start over preserves the previous version. Local plans continue into implementation on the same ticket after you select an executor and approve its permissions. Opening Combined plan or Implementation reveals its result and next action. The implementation keeps its own model settings and permission choices, and the ticket retains planning revisions and implementation history.

Shared plans use the same ticket for implementation. Select the executor, review its model/settings and prepared location, then ask its owner to approve before starting. The implementation chat supports follow-ups, @ context and owner approvals. A teammate's follow-up waits for the executor owner's approval; the card shows executing work and its reported settings. Failed submissions keep their prompt for recovery. These shared flows have passed tests with two accounts on one Mac against a local server; the two-Mac acceptance run is still open.

Projects group tickets for a client or body of work across repositories. Assigning a project does not move a working directory or grant Git access. Planning documents budgets, cancellation, history and the remaining shared implementation limits.

Shared planning records each planner's Mac or Cloud assignment. A moved session requires review before Start. Once queued, a plan keeps those assignments; a changed or unavailable destination stops the next phase and preserves completed drafts. Start over creates a new revision with reviewed locations. In a shared draft, Run on below each planner's model settings selects its Local or Cloud source separately. Choose a prepared cloud workspace or a session on this Mac, then apply the selection. Other planner settings and attached context stay unchanged. Running shared plans show each provider's output as it arrives, with reported model settings. Reopening the plan replays its saved stream; access changes hide the affected output. Native visual and live cloud validation are still open.

Memory and Cortex consolidation are deferred until Cortex is ready. V1 has no memory API, consolidation action or Cortex service dependency. Shared Markdown skills remain in scope. See the deferral record.

Choose Save to Camp from a local planning or implementation card's menu, or the cloud icon in the plan window. Review the destination project and choose Save privately. Camp copies the saved plan revisions, quoted context, implementation chats, attempts and model settings without starting a provider turn. Progress continues after closing the review window. Retry resumes a failed upload; restarting the app restores the approved import. See local-plan import.

The original ticket remains on this Mac. Once the same snapshot is saved, its Camp card takes its place in the board. Newer local work remains visible, and signing out restores the local view. Open the saved plan's History view to inspect implementation chats and attempts. Start over retains quoted context in a new draft; removing a source there leaves the saved version intact.

Source copies are read-only and stay under their parent plan. Profile paths, credentials and project files are excluded from this history import. Continuing with an agent requires a new, reviewed execution assignment. Native visual acceptance and two-Mac validation are still open.

Default execution settings

Open Manage sources → Defaults, or use the Defaults step during setup. Choose Local or Cloud, an optional provider for single-model plans, and a profile or account for each provider. Automatic provider selection uses the selected session when available, then an available provider. A Cloud default also needs a shared Camp project. These preferences are saved on this Mac, separately for each person, Camp and server.

Prepare at least one session workspace in that project through Run on. New cloud plans use the most recently updated eligible source for the selected account and open a private draft for review. They do not start provider work until you choose Start. If the account, profile or workspace is unavailable, Camp asks you to fix that selection. Existing tickets keep their assignments. Plan on this Mac explicitly overrides the default location for a new plan.

Permissions and notifications

Open Permissions from a card's menu or the shield in chat. Imported sessions start in chat preview mode. Enabling project tools requires an explicit choice; the installed CLI enforces its available policies. A change applies to the next turn, and a queued prompt with outdated permissions needs review. Approval requests appear in chat and move the card to Needs you.

The notification bell opens saved completions and unread items. Use Tab to reach inbox entries and Space or Return to open a result. Foreground completions show a toast. Desktop notifications are opt-in; title previews and sounds are separately optional. See permissions and notifications for the exact behavior.

Usage limits

When a Codex or Claude account hits its session or weekly limit during a Camp turn, Camp moves the session to the next signed-in account of the same provider and keeps going. The card keeps its place, the chat shows one line such as "Continued on .codex-pipeline · Weekly limit on .codex until Oct 28, 5:53 PM", and the inbox gets an info notice that arrives already read. Queued prompts, permissions and model choices follow the session. An account that keeps working on credits or paid overage isn't treated as blocked. If every account is at its limit, the card moves to Needs you, says when it resumes, and its queue resumes on its own when the first account resets.

Auto-continue is on by default. Open Manage sources → Usage limits to turn it off, drag the profiles into the order Camp should try, leave a profile out, and see each account's usage and reset times. It covers Camp's own chat turns in local sessions on subscription profiles. API-key and model provider profiles, plans and their implementations, shared sessions and the first turn of a New session stop at a limit as before. It has not yet been checked with two real accounts at their limits. See auto-continue for the details.

Model providers and new sessions

Open Manage sources → Model providers, or Add a model provider… in the sidebar's + menu, to run Codex against Venice AI, OpenRouter, Hugging Face or a custom endpoint that serves the OpenAI Responses API. Camp checks the key with the provider's model list and one short streaming request, keeps the key in the login Keychain, and creates a Codex profile named after the provider. Its sessions use the same chat, planning, implementation, permissions and queues as any other Codex session. Provider profiles need Codex 0.163 or later. They don't take attached @ sessions yet, don't run teammates' requests and can't run in the cloud. See model providers.

New session in the header (⌘N) starts a Codex session in any Codex profile, provider profiles included. Choose the profile, model, project folder and first message, and whether Codex stays chat only or can edit that folder.

Shared Camps and cloud execution

Sharing works with any Camp server. The hosted server at https://api.capybaracamp.com is the app's default and accepts invited addresses only during the pilot; anyone else can run their own server from the self-hosting guide. Cloud execution needs a server with the isolated runner overlay. No public runners are offered, and no live cloud provider turn has been accepted yet. The remaining acceptance work is in the delivery status.

Every collaborating Mac connects to the same HTTPS Camp service. Each person signs in with their own email, then creates or joins a Camp. On a session card, Share with Camp selects its project and whether teammates may request work. Another person's request requires the session owner's approval. Stopping sharing removes teammates' access and cancels queued requests. Private local imports are not automatically uploaded.

The cloud service is Go with PostgreSQL. Native clients keep a scoped SQLite cache and a durable offline outbox. The owner-Mac worker runs approved local requests; a separately provisioned cloud installation runs assigned cloud requests. The service retains transcripts and ordered events so clients can reconnect. Independent Camp deployments do not synchronize with each other.

Connect provider accounts and GitHub

1. Connect the app to your Camp service.
2. In Manage sources → Cloud accounts, add each Codex or Claude account separately. Complete that account's official provider sign-in after its isolated runner becomes ready. Local profile credentials are not copied.
3. Connect your own GitHub identity and select an available installation.
4. Link a repository to the Camp project. A project link alone does not grant repository access.

Cloud accounts belong to their owner. Other Camp members do not receive their credentials. Account identity comes from successful provider verification, not its label. Missing server configuration or an unavailable runner appears as a visible setup state. Reconnect uses the same verified identity; provider login expiry and usage limits remain under the provider's control.

Move a ticket to Cloud

Open Run on from the card or chat. Review the private transcript copy, provider account, GitHub identity, project repository and pinned revision. For a local session, open Run on → Cloud, choose the destination provider account and GitHub repository, then choose Review move. Every working file that can move starts selected; clear the ones to keep on this Mac. Moving with none selected asks first, because the cloud session then starts from the last commit. Inspect the captured contents and exclusions, and choose Prepare Cloud. The review pins the current local Git commit. That commit must already be available in the selected remote repository.

Review waits for the current main and subagent histories to finish syncing. The capture binds their content revisions to the imported cloud revision and shows the subagent count. The source checks that same history before the final move, so an edit after review requires a fresh copy and review.

Once the cloud is ready, choose Pause and check on the original Mac. Camp checks that the provider has stopped and the selected files still match. If the session, workspace or hold changes before the move, choose Cancel and review again to start over from file selection. Review the destination permissions, then choose Move to cloud. The ticket keeps its main conversation and saved child transcripts as imported context. The cloud agent can read both through the Camp context tool. File attachments, unpushed commits and full migration acceptance still need the work listed in the delivery status. Copying a transcript privately does not share it with teammates.

Cloud assignment stops the local publisher from overwriting the cloud session. Returning an unused checkout to Local preserves the local draft and project. A used checkout requires the reviewed transfer feature, which is still pending; the current app blocks that move. The local runner implementation retains a separate checkout and provider history for each ticket and schedules work serially per account. Cloud controls use the same steer, queue and stop actions as local chat, with durable delivery tracking. The runner can read its complete stored conversation through the context tool in bounded pages, including long messages. History remains pinned to the queued prompt and each page checks the current request and permissions. The agent uses list_subagents to find attached child histories, then read_session to read only the ones it needs. The child catalog and history use the same pinned parent revision. Saved child histories are also readable separately in the native sidebar; file attachments still need migration support. Default settings, the prepared-workspace requirement and unfinished transfer behavior are documented in execution locations and the delivery status.

The Go API includes encrypted, resumable uploads for reviewed file-transfer manifests. An owner-authorized Cloud destination job connects the upload to the runner, stages files in a private checkout and validates its receipt. These are parts of the transfer flow: an upload alone does not move the session or apply files. The source cloud runner can now verify an idle provider and the reviewed files under a temporary session hold. It retries lost acknowledgements without restarting the provider. The Mac worker also holds the local conversation lock while the bundled Go helper checks its source files. The owner can request the final move with explicit destination permissions. The source then checks the files again before the server changes the execution epoch once. During the source hold, the Mac waits for saved, visible routing before releasing its lock. The cloud worker reconciles a lost completion response from its journal. The server retains the committed receipt and removes the temporary upload chunks. Cloud runners also support owner-selected source exports: inspect changed paths, capture the selected files with credential exclusions, and resume encrypted chunk uploads after a restart. Each export expires after ten minutes and reserves the runner while capturing. This is a backend component of Cloud-to-Local migration; native reverse-transfer review and attachment installation remain unfinished. See the export contract. The local destination API now accepts an owner-Mac receipt and explicit context continuation approval. A fresh source stop proof then moves the same ticket to the selected local profile while preserving its shared parent/subagent history. Native continuation and the reverse-transfer review remain open; this backend path does not yet provide a complete Cloud-to-Local journey. The native history downloader preserves pinned parent and subagent messages in a resumable local cache, with integrity and permission checks before it returns an archive. Real local API tests cover both providers. The bundled installer now preserves that archive privately alongside reviewed files in an existing isolated checkout, with restart recovery and a receipt bound to the selected profile. The Go checkout preparer can create that private workspace at an exact remote commit, sharing the cloud runner's Git safeguards. The API issues a short-lived, repository-scoped read grant to the signed-in owner device, and the native coordinator passes it directly to the helper after verifying the reviewed export. A saved native preparation journal resumes checkout and installation across restarts, preserves the selected profile, and prevents cancellation from being overwritten by a late helper response. The return handoff coordinator now uploads that reviewed snapshot, obtains the source hold and saves explicit continuation/implementation approval before confirmation. Restart and lost responses reuse the saved operation keys. The server changes ownership only after the source answers the stop proof; a committed move retains the same ticket and parent/subagent history. The local conversation transport can attach the installed archive through the existing read-only Camp context tools, with bounded pages and original message links. It verifies the receipt and selected profile/checkout; it does not create a provider conversation or authorize execution merely by attaching history. Completed handoffs can now be adopted into a private per-ticket/execution-epoch binding. The Camp ticket keeps its identity while the binding records the actual CLI conversation ID. A durable launch reservation prevents replaying the first submission after a crash; an unknown outcome requires review. The native transport can persist the ID before forwarding the session event and rejects malformed or conflicting identities. The native worker resolves adopted transfers from these bindings, reserves each launch before process creation, and supplies the complete installed archive through the existing context tools. Implementation uses the committed permissions and a fresh CLI context check; a planning-purpose continuation uses read-only chat. Subsequent prompts resume the saved provider ID. Schema 37 lets an admitted continuation on the assigned Mac use the existing ordered stream, steering and approval paths. It records the provider conversation on the committed handoff and appends new messages after imported history on completion. Replayed events and completion acknowledgements do not duplicate messages. Ordinary transcript publication cannot replace that history or publish the bound provider conversation as another ticket. The native stream reader recognizes these local turns and hides their temporary output once saved. The transfer review/adoption screen, local duplicate-card suppression, missing remote commits, attachments and live provider acceptance remain unfinished. The native publisher includes saved subagent histories with a shared or private Camp copy. Child transcripts stay under the parent's permissions and have their own message IDs and paged history. The sidebar refreshes after child updates, and a child can be opened without mixing its messages into the main chat. Model citations open the specific child message in the native snapshot inspector, with a link back to that child conversation. Previously opened child catalogs and pages are saved in a bounded offline cache. An label identifies a saved transcript; access changes and removals invalidate it when observed. Uncached history and exact citation inspection require a connection. See .

The native review stores its selected payload separately from its small recovery journal. Interrupted uploads reuse their saved command keys and missing chunks. A rejected operation pauses for explicit retry or cancellation. Closing the dialog keeps an active transfer running; cancellation is saved before the app sends it to the server. These controls still require the final live-provider and two-Mac acceptance tests, alongside child-session, attachment and cloud-to-local migration. The bundled helper now blocks the original local session across a hold timeout or app restart. Confirmed cancellation restores local execution; a completed move keeps the old source blocked. After sign-out or cache erasure, signing in to the same Camp recovers saved blockers from the local helper and checks them against the owner's server records. Confirmed cloud assignments return to the app; confirmed cancellations release the original local session. Complete migration acceptance remains unfinished. See the transfer contract for ownership, limits, recovery and the remaining handoff work.

For operators, start with self-hosting, then the runner provisioning guide. The repository includes public Kubernetes and Hetzner K3s templates. Deploy the base Camp service and enable the isolated runner overlay only with its required storage, credentials and Linux isolation support. Hardware purchase and live deployment remain separate acceptance steps.

Data and privacy

Camp stores source paths, cached metadata, board positions, model settings and queued prompts under ~/Library/Application Support/Capybara Camp. CAPY_SUPPORT selects a separate absolute directory for testing. Provider credentials used locally stay in the provider's own storage. Import reads are local; sending a prompt uses the selected CLI and updates that provider's store. API keys for model provider profiles are the exception: Camp keeps them in the login Keychain, and each Codex launch only sees a loopback token that stops working when the launch ends. See model providers.

Cloud-only conversations and unreadable files belonging to other macOS users are not imported. Camp uploads a session only after you share it or make an explicit private cloud copy. Private copies remain owner-only. Cloud provider sign-in creates separate encrypted credentials on the configured service; it does not upload a local credential directory.

Normal builds use HTTPS and store Camp device credentials in the macOS Keychain. Never attach profile directories, the application-support folder, provider credentials or unredacted transcripts to an issue. Report sensitive findings through the process in SECURITY.md.

Development

./test.sh
./tools/test-server.sh
./tools/test-native-api.sh
./tools/test-processguard.sh
./tools/test-release.sh
./build.sh --universal

test.sh runs local Go protocol tests and the native state suites with synthetic provider processes. Its bridge integration suite packages a disposable Mac app with the real Go helper and exercises recovery through the production command dispatcher. Its support directory is isolated from the user's sessions. Suites run on a one-thread Swift concurrency pool (LIBDISPATCH_COOPERATIVE_POOL_STRICT=1), so a pipe read or process wait left on that pool hangs on every Mac, as it did on three-CPU CI runners. Each suite has a deadline (CAMP_SUITE_TIMEOUT, 300 seconds by default), and testCase(_:) names the case that stalled. tools/test-server.sh requires Docker and starts disposable PostgreSQL for Go race tests and vet; it removes the container on exit. An explicit CAMP_TEST_DATABASE_URL uses isolated schemas in that test database instead. Never point it at production. Its two-account HTTP journey signs in independent users through the real OTP endpoints with a captured test mailbox, saves separate device credentials, joins a Camp, shares a session, obtains owner approval and replays events after restarting the API. It checks private-session isolation, idempotent prompt retries and membership/device revocation. PostgreSQL and HTTP are real; worker completion is synthetic and no provider is called. Native client, live-provider and two-Mac/cloud acceptance remain separate checks. tools/test-native-api.sh runs the Swift execution-review coordinator and local worker against a fresh loopback Go API and disposable PostgreSQL. Two users with separate device credentials complete Codex and Claude implementation journeys. It verifies owner-only approvals, isolated provider conversations, streamed responses and settings, approval replies, recovery after lost responses, and completion on the original ticket. Provider subprocesses and local permission inspection are synthetic; personal profiles are never used. The script removes its temporary credentials, caches and database on exit. The native suite skips this journey during ordinary test.sh runs unless the explicit fixture is set. tools/test-processguard.sh exercises the required Linux process boundary; on macOS it uses Docker. tools/test-release.sh checks notarization recovery and packaging with synthetic Apple tools. It needs no certificate, Apple login or provider account.

These tests do not require real provider accounts or API keys. They cover import isolation, transcript notifications, streaming, cancellation, steering, queue recovery, auth and durable server state. They do not replace live provider, two-Mac, deployment or UI acceptance. Current evidence and CLI versions are recorded in the relevant guides and UI audit.

The build and test suite use Swift and Go. test.sh builds a separate Go fixture executable for native protocol tests; that executable is never included in the app. The migration record maps the 103 former Python tests to their replacements.

By default, builds go into build/ and use ad-hoc signing. Set CAMP_SIGN_IDENTITY for your own certificate, CAMP_APP_PATH for a different output bundle, or CAMP_BUNDLE_ID for a different identifier. The default identifier is com.capybaracamp.app. Repeated builds keep that identifier; a matching binary hash across different builds is not promised.

Isolated native QA

For isolated native/Go integration tests, run tools/native-fixture.sh with an absolute temporary directory, then build with ./build.sh --development. The fixture starts disposable PostgreSQL and a loopback API; it writes synthetic email codes to that directory. Development builds allow a loopback HTTP origin. CAMP_DEV_EPHEMERAL_CREDENTIALS=1 uses in-memory Camp credentials in those builds. Normal builds require HTTPS and use the Keychain. Set CAMP_NATIVE_FIXTURE_IMPLEMENTATION=1 when starting the fixture to seed a completed shared plan and a separate executor's implementation. Sign in as [email protected] and [email protected] in separate development app bundles with separate CAPY_SUPPORT directories to test follow-up approval and synchronization. Provider output is synthetic; the fixture never invokes a provider CLI. Point CAMP_DEV_PROFILE_ROOT at an owner-only fixture directory to keep automatic discovery away from personal profiles. Keep CAMP_UI_AUDIT=1 set so a helper without fixture support refuses to scan. An explicit CAMP_TEST_DATABASE_URL also works with the native fixture. Use a dedicated disposable PostgreSQL 17 database; the fixture creates an isolated schema and removes it on exit. It must never point at production.

Troubleshooting

• A profile is missing: finish provider CLI sign-in, check file access, then use Manage sources for a custom location. Do not copy another user's credentials.
• A session cannot send: release it from its original client. Camp does not take over another client's active session.
• A response is delayed: Camp-started output streams directly; external output depends on what the original CLI writes. Check its activity and login state.
• Cloud setup is unavailable or waiting: check service configuration, account provisioning and runner readiness in the operator guides.
• A request has an unknown outcome: review it before starting again. A lost connection is not proof that the provider did no work.
• Desktop alerts are missing: enable them in Camp and macOS settings. The saved notification inbox remains available even when the system suppresses an alert.

Documentation

Guide	Covers
Onboarding	Automatic discovery, optional connections and resume
Planning	Single/comparison plans, budgets and implementation history
Projects	Private/shared projects and repository links
Session context	@ references, message ranges and source permissions
Session permissions	Provider policies, queues and approval changes
Model providers	Venice AI, OpenRouter, Hugging Face and custom endpoint profiles, keys and the helper contract
Notifications	Toasts, inbox, desktop alerts and cross-device state
Auto-continue	Continuing on another local account at a usage limit
Cloud accounts	Account ownership, login and credential lifecycle
GitHub	GitHub App setup, repository authorization and checkouts

Website

The public website is hosted on Cloudflare Pages at capybaracamp.com, using the capybara-camp Direct Upload project. Its source is docs/index.html; a Cloudflare Redirect Rule sends the www address to the main domain.

The current page is self-contained. Its upload ZIP contains only index.html at the archive root. Do not upload the repository or a build directory, which can include local diagnostics. The planned native demo will need explicitly listed media assets in the website package. Cloudflare Direct Upload is separate from GitHub pushes; GitHub Pages remains a preview mirror.

Releases

The release procedure requires the full acceptance gates, updated README and versioned release notes, a final code push, a tag pointing to the tested commit, and a published GitHub release with verified artifacts and checksums. The website must show matching downloads and a recorded native demo.

./tools/package-release.sh --development creates an explicitly named development archive. Public candidates use --release with a Developer ID Application identity, an expected team ID and a saved notarytool credential profile. That path checks both architectures, submits to Apple, resumes processing by submission ID, staples the accepted ticket and verifies the extracted archive. It writes the app, setup HTML, notes, build information and checksums under dist/vVERSION/. It refuses to overwrite an existing artifact directory.

Packaging does not push, tag, publish to GitHub or deploy the website. v1.5.0 is ad-hoc signed and not notarized, as v0.0.1 was; the packaging script has no mode for that build, since --development marks its archive DEVELOPMENT and --release requires notarization. A notarized release follows the release procedure after the full V1 acceptance work passes. The tooling's synthetic tests are not evidence of a notarized build.

Scope and remaining work

A notarized V1 release still needs the unfinished cloud, shared skills, Git publication and validation work listed in the delivery status. OpenCode support is a design spec only. Auto-continue moves a session only between your own signed-in local accounts of the same provider, says so in the chat, and can be turned off. Guaranteed perpetual login and silent execution fallback are excluded. macOS Dictation is the chosen input path; provider-native voice transcription is not included. Each release is described in releases/.

Source layout

• Sources/CapybaraCamp.swift: SwiftUI app and native state
• Sources/CampConnection.swift, CampHTTP.swift, CampCache.swift: native Camp connection, event stream and durable local cache
• Sources/CampCredentials.swift: origin-bound native Camp device credentials
• server/: Go API, PostgreSQL migrations and permission/lifecycle tests
• server/cmd/camp-local/, server/internal/localcli/: bundled Go imports, live observation, conversations, approvals and attached context; migration status
• deploy/: public Kubernetes and Hetzner K3s templates
• server/cmd/camp-test-provider/, Tests/FixtureProcess.swift: test-only native protocol fixtures
• Tests/: fixture-only tests
• docs/index.html: self-contained setup page with the generated mascot
• releases/: versioned release notes

The capybara mascot was generated with an image-generation tool; its brief is in Resources/logo-prompt.txt. Capybara Camp is independent of OpenAI and Anthropic.

License

A source license has not been selected yet. Publishing this repository does not grant a general license to redistribute it.