Flock policy

How to read this page

Product behavior is what the flk binary verifiably does in this release; every such statement here carries evidence in the product tree. Legal interpretation is not offered: this page is not legal advice, it makes no blanket compliance guarantee, and the providers' published terms govern your accounts. Flock is for orchestrating accounts you hold yourself.

Assignment outcomes

Dispatch checks eligibility before delivery. The task ledger records failures and any collected result; an eligible target can still be busy, unavailable or blocked at its composer.

Situation	Outcome
An eligible profile exists inside the declared owner boundary	The task is dispatched to that profile's live session; the routing reason and result are recorded on the task.
The dispatch crosses a declared owner boundary	Refused unless the sender explicitly confirms; the confirmation is recorded on the task.
The target profile is logged out	Refused before any session is created.
The target profile's capacity is determinately exhausted	Refused, and `claude:auto` skips it. Flock does not work around a provider limit.
The capacity reading is indeterminate (stale, unknown, or drift)	The profile stays routable for dispatch, with transcript metering as the floor; succession and retirement take no action, and the reason is shown.
The worker hits blocking ambiguity	The task settles as `needs-clarification` with the worker's questions as its result; it can be answered and redispatched up to three rounds.

Provider accounts stay separate

Each profile selects a provider CLI and an account binding. Profiles can share an account and its limits. Separate profile homes are the default; adopted homes retain their existing paths. Provider credentials may live in those homes or the macOS Keychain. Flock does not exchange credentials between providers. The checked flk source calls no OpenAI endpoint directly.

Anthropic: Consumer Terms of Service Anthropic: Usage Policy OpenAI: Terms of Use OpenAI: Usage Policies

Provider terms govern the accounts. These links are references, not a legal compliance assessment. No current legal review is asserted by this release audit.

Owner boundaries

flk account add requires an owner declaration. Some onboarding paths can default the owner to the account name. Delegation compares the sender and target accounts when both owners are recorded; differing owners require explicit cross-owner confirmation, which is recorded on the task. Flock does not verify legal ownership.

Capacity checks and uncertainty

Automatic routing filters to logged-in profiles of the requested provider and skips determinately exhausted dispatch capacity. When every candidate has fresh quota data, it chooses the lowest worst-window percentage; otherwise it compares transcript usage. Claude quota comes from its usage endpoint and Codex readings come from local rollouts. Gemini has no numerical quota reader; observed refusal signals are recorded separately.

Quota readings older than 90 minutes, errors, unrecognized shapes and passed reset deadlines are indeterminate. Dispatch leaves those profiles eligible; quota-driven lead succession requires determinate capacity. Claude credential-file reads do not require macOS Keychain access; Keychain reads require access to that store.

What Flock records

Recorded locally

Flock keeps account and profile configuration, session records, lifecycle events, quota responses, the lead lease, task briefs and results, and mailboxes as local files. Task records name the target profile and routing reason; unsuccessful tasks may have no result.

Credentials and supplied content

The quota cache stores usage responses and identity bindings, not the access token read for a quota request. Isolated provider homes can contain credentials and transcripts. Task briefs, results and notes retain the content supplied to them, including any secrets.

The default root is ~/.flock; FLOCK_HOME overrides it. Uninstall retains state unless --purge-state is requested. Purging includes isolated profile homes and their credentials; review that scope before confirming.

Credentials

Discovery attaches existing provider homes in place without importing their credentials. Claude quota checks read the credential file or macOS Keychain and send the token to Anthropic's usage endpoint. A mismatched profile login can quarantine credential files and remove the profile-specific Keychain entry. Provider login tools keep credentials in their own stores.

What the binary sends

The checked flk source makes direct HTTP calls to Anthropic's usage endpoint with the profile's bearer token, and to flk.dev/dl for release checksums and binaries. It contains no product-telemetry sender or network listener; MCP uses stdio. Claude Code, Codex and Gemini CLI make their own provider calls.

The optional macOS quota LaunchAgent runs a persistent flk quota watch process. It refreshes at a 15-minute cadence, known reset deadlines and requested refreshes, using the FLOCK_HOME recorded in its plist. Obtain consent before installation; flk quota uninstall-agent or flk uninstall removes it.

Website measurement

Website analytics are separate from the flk binary. This section describes the site code checked for this release; analytics settings outside the repository are not attested.

The site template loads Google Analytics. The local adapter allows named events for page views, prompt-copy results, guide links, walkthrough controls, trust links and outbound links. It filters property names and truncates primitive values; it is not a secret-redaction boundary. The site's copy control does not pass the copied prompt text to the adapter. If gtag is unavailable, adapter calls return without sending.

The local analytics adapter does not instrument binary downloads. CDN logging and Google Analytics account settings are outside this source audit. Google's privacy policy

Release limits and changes

This is an alpha release for macOS and Linux. Binaries are unsigned. Two integrity mechanisms are published: the SHA-256 checksum file beside the artifacts, which the install runbook and flk upgrade both verify against, and a minisign signature on that checksum file (public key pinned in the runbook and at /dl/minisign.pub), which the runbook verifies before comparing digests.
Releases are checksummed binaries; the source repository is not public today.
This policy describes the release shown above. A release that changes credential handling, networking, recorded state, or assignment gates needs a corresponding dated policy update.

Questions

Questions about this policy or the product: info@thomasgrange.com