grithdocs

Team setup

pro

Getting a team onto grith: what each machine does for itself, what syncs, and what never leaves the developer.

Pro

Every developer runs their own grith on their own machine. There is no shared daemon and no central enforcement point - that would put the thing making security decisions somewhere other than where the code runs. What a team shares is the licence, policy, shared configs, provider keys, and an aggregated view of what happened.

1. Install and sign in

On each machine:

terminal
$ curl -fsSL https://grith.ai/install | sh
terminal
$ grith init
terminal
$ grith pro login

grith pro login opens a browser and runs device authorisation - it prints a verification URL and a user code, then polls until you approve. --api-key <key> skips the browser if you already have a key. Check where a machine stands at any point:

terminal
$ grith pro status
Not logged in.
Run: grith pro login
     or: grith pro login --api-key <key>

Once licensed it prints the plan, tier, team, seats, renewal date, when the licence was last validated and when it refreshes next.

2. Pull the team's policy

terminal
$ grith pro sync

Sync pulls team policies into ~/.config/grith/policies/, shared configs into configs/, provider API keys into provider-keys/ - deleting any key the team has since revoked - and the team's shared learned rules into a local cache. It pushes the machine's learned reputation table. It refuses on a community licence.

ℹ️No command uploads your audit log

The raw audit-record upload was retired. Sync uploads no audit records, and there is no command that does.

Provider keys land encrypted at rest, sealed to your grith API key rather than a passphrase or the OS keyring. That means anyone holding the account's API key can decrypt them, and rotating the key makes the existing files unreadable. See Encrypted key management.

3. Analytics

On a paid plan, a signed-in machine turns cloud analytics on by itself. Four things must all be true: a paid plan, a signed-in account, recorded consent, and general.audit_sync left on.

terminal
$ grith analytics status
Cloud analytics sync
Consent:  not recorded yet — turns on automatically with a paid plan
          (or run `grith analytics enable`)
Account:  not signed in — run `grith pro login`
Plan:     requires a Pro plan
Config:   audit sync on
Device:   not registered yet
Pending:  0 day(s) awaiting upload, 0 security event(s)

Before consent is recorded, grith analytics enable prints exactly what will be sent and asks. What goes up is aggregate: counts of allowed, queued and denied operations by hour and day; filter activity and score distributions; session, project, profile and tool names; model usage and estimated cost; and summaries of what was blocked and why. Once a UTC day closes, that same day is also uploaded as one file to encrypted private storage and kept for 90 days.

It never includes commands, file paths, file contents, prompts or model responses.

grith analytics disable stops it on that machine. To check the archives agree with what the dashboard is showing:

terminal
$ grith analytics verify-archives

It re-downloads each archived day, rebuilds the numbers, and exits non-zero if any day disagrees - which makes it something you can run on a schedule rather than read.

What moves between machines, and what does not

WhereOn a new machine
Your config~/.config/grith/config.tomlCopy it, or run grith init and re-apply your changes
Licence and credentials~/.config/grith/credentials.json, license.keyNever copy. Run grith pro login
Team policies, configs, provider keys~/.config/grith/policies/, configs/, provider-keys/Arrive with grith pro sync
Learned reputation~/.config/grith/reputation.tomlPer machine. Pushed to the team on sync; a fresh machine starts with an empty table and re-learns
Audit log~/.local/share/grith/audit/Stays. It is machine-local evidence with its own hash chain, not something to merge

If you keep dotfiles in a repo, config.toml is the only one of those that belongs in it.

What the team dashboard shows

Rollups and a Security events timeline - what was blocked, when, by which filter, and how it was resolved. It is not a copy of anyone's audit log. Audit records stay on the machine that produced them.

See also

Last updated: 2026-08-24Edit this page on GitHub →