Security
Partyline has no hosted backend. Session records stay in the files your engines write locally,
repository memory stays with the code, and chat history is stored under ~/.partyline/.
Local storage does not mean local model inference. Agents receive memory and chat messages as context and use their configured providers. Partyline also invokes Claude Code and Codex for the AI features listed below, using your accounts.
Network requests
| Request | When | Carries | Turn off |
|---|---|---|---|
GitHub API, latest release of partyline-sh/cli | at most once a day, and on ptln version | no install identifier or repository content; GitHub sees your IP address | PARTYLINE_NO_UPDATE_CHECK=1 |
| release downloads from GitHub | ptln upgrade, or the install script | no install identifier or repository content; GitHub sees your IP address | do not run them |
gh pr checks, through your gh login | every 2 minutes, for up to seven days, for a passed loop whose session recorded a PR with ptln loop pr | the PR number or URL | do not record a PR |
Jev (api.typesafe.ai) | when a loop decides a dispute and a Jev key is saved | the brief (up to 6,000 characters), the disputed finding and the session's reason | remove the key in the loop settings |
| your chosen Go or Cloudflare relay | only after you set up Mobile remote | encrypted content, routing identifiers, addresses, timing and sizes | do not configure remote access |
| Cloudflare deployment API | when deploying/updating a Cloudflare Worker relay | Worker code and deployment credentials | choose a Go relay instead |
| Let's Encrypt ACME API | only with explicit --acme relay hosting | gateway hostname and certificate issuance | use your own certificate or HTTPS proxy |
| local multicast discovery | while private gateway discovery/advertising is enabled | friendly name and HTTPS origin, no keys or session content | do not enable discovery |
The Partyline CLI sends no telemetry or crash reports. Failures are reported locally in the terminal or the private phone-session log.
AI requests and account usage
| Feature | What the model receives | Control |
|---|---|---|
| Project overview generation | repository content read by claude -p with read-only tools | runs when ptln memory build --apply needs to generate an overview |
| Automatic memory capture | recent Claude session transcript content, sent to a separate claude -p invocation to propose durable facts | set PARTYLINE_MEMORY_CAPTURE=off to disable |
| Agent sessions and chat replies | prompts, applicable repository instructions, and delivered chat messages | your engine's provider and permission settings |
| Loop reviewers, and the model that rules on a dispute | the brief, the session's report and the diff, or the disputed finding and the session's reason; read-only access to a snapshot of the work | the models chosen in the loop settings |
| Loop builders | the batch step's brief, findings and check output, with your own engine setup and write access to the checkout | the builder chosen in the loop settings |
Overview generation and capture use your Claude account and can consume additional usage.
Automatic capture runs only in repositories with memory/, records at most two facts per capture,
and is throttled to at most once every 20 minutes per session. Proposed facts still need review.
Your repositories
partyline never pushes, merges, opens pull requests or rewrites history. It commits only one thing:
a loop batch step that passed its checks and review, on the batch's branch,
authored as <engine> <model> via partyline. Facts are written to the working tree for you to
commit. Whether a directory is your repository or a partyline-owned clone is decided by its
location, not by a flag.
Loop builders run with your own engine setup, credentials and MCP servers. They cannot push, merge or
open a pull request, and cannot change ~/.partyline, where approvals and rulings are kept; see
Loops.
What the chat types into sessions
The chat room types one line into a session, a pointer to ptln chat read, only when the session's
pane is not shown on an attached terminal, the session is not working, and its input box is empty.
It never types into a box that contains text, and it strips control characters from messages before
displaying them, so a message cannot set your clipboard or window title. See Chat.
Remote clients and private gateways
A phone pairs separately with each computer after a code comparison and computer approval. Gateway membership is a different approval; joining a gateway never pairs a phone automatically. Native keys and device tokens use device secure storage. Browser-client keys depend on that browser's storage and the code served by the relay. A compromised relay can serve modified PWA code; asset checks can detect a difference against a saved baseline, but cannot prevent targeted delivery of different code. Native UI code is bundled with the installed app.
A Go relay needs trusted HTTPS externally. Its plain HTTP listener is loopback-only.
Behind a reverse proxy, trust only that proxy and configure it to append or
overwrite the actual client IP in X-Forwarded-For. The relay uses only the
rightmost hop supplied by the trusted immediate peer; arbitrary callers cannot
supply trusted addresses. HTTP requests, unauthenticated connections, pending joins
and peer buffers have limits. Missing forwarded addresses can make clients share
one rate-limit bucket.
A private gateway join uses Noise XX with a commitment before the gateway's response and a checked reveal. Compare the six-digit code on both computers; only the owner can approve. Discovery does not authenticate an advertised name. The private data directory is 0700 and its credentials/registry are 0600. Setup reviews service installation before applying it. Services run as your user; another program running as that user can still access that user's files and credentials.
A paired phone can upload files into its own computer-chosen cache directory, limited to 20 MiB per file and 200 MiB per phone. Files are private and non-executable, with size and SHA-256 checks. Uploading adds a path to a draft, never a Send action. Phone layout is a separate opt-in that changes the same single-pane tmux window on the computer until released or its lease expires.
See Mobile remote for pairing, storage paths, update channels,
revocation and troubleshooting. The repository's SECURITY.md describes the threat
boundaries and vulnerability reporting process.
Signed releases
Every release's checksums.txt is signed with cosign in keyless mode. The signature is published
beside it as checksums.txt.sigstore.json, plus checksums.txt.sig and checksums.txt.pem for
cosign 2.x. Keyless means there is no long-lived signing key: the certificate is issued for one run
of the release workflow from that workflow's OIDC identity, expires minutes later, and is recorded
in sigstore's public transparency log.
Verification checks the workflow that produced the release,
…/partyline-sh/partyline/.github/workflows/release.yml@refs/tags/v…, so an artifact uploaded any
other way fails, and so does a checksums.txt changed by one byte. The commands are in
Install.
install.sh and the Homebrew cask both verify before anything is installed, and every failure
aborts with nothing installed: no cosign, a signature that does not verify, a signature from
another repository or workflow, a missing signature file, a mismatched checksum. No flag or
environment variable skips verification or chooses which cosign runs. The cask also checks that the
sha256 it pins is listed in the signed checksums.txt, so the tap repository is not the only
thing trusted.
Both test the verifier before trusting it: after cosign accepts the real checksums.txt, they give
it the same file with one line appended and require it to reject that. A cosign that approves
everything, such as a wrapper earlier on PATH, fails that check and the install aborts.
The installer does not remove com.apple.quarantine on macOS. The macOS binaries are notarized by
Apple and pass Gatekeeper.
Source
MIT licence, at github.com/partyline-sh/cli. Install covers building the binary yourself.