📝 Document Signing In As Yourself In The CLI Guide - #295
Open
dunningdan wants to merge 3 commits into
Open
Conversation
The page described the shared API key as the only way to authenticate. The CLI now signs users in through their deployment's identity provider by default, and ordinary commands use that session, so the documented flow was both the harder path and no longer the one most readers want. - Leads with signing in as yourself: no admin-console token needed, actions attributable to a person, and the browser need not be on the machine running `pixee` — which matters for SSH sessions. - Keeps the shared API key documented for CI and unattended use, where nobody can approve a prompt. - Corrects credential resolution. It read `PIXEE_TOKEN` -> stored config, which omitted the session entirely; it is now `--token` -> session -> `PIXEE_TOKEN` -> stored key, with the note that only an explicit `--token` outranks the session. CI is unchanged: a runner has no session, so it uses the key. - Refreshes the `pixee auth status` example, which quoted output from two revisions ago, and adds the `auth` subcommands to Common Commands — the group had no entry there at all. - Notes that a permission change reaches the CLI at the next refresh, within one token lifetime. The removal direction is the one worth knowing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The exit-code-2 step said to "reset both with `pixee auth login`". A bare `auth login` now starts a browser sign-in, which cannot complete on a build runner — the one place this page's readers are. Point at the pipeline credentials instead (`PIXEE_TOKEN` / `PIXEE_SERVER`, or `--token -` to store a key), and say plainly why the interactive form is not an option here. Also nudges toward `auth status`'s new line naming which credential will actually be sent, since a mismatched pair is the usual cause. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rewrites the seven em dashes this branch introduced as semicolons, full stops, or plain clauses. No wording or meaning changes beyond the punctuation. Pre-existing em dashes elsewhere in the file are left alone; they are not part of this change and rewriting them would bury the substance in noise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dunningdan
added a commit
to pixee/pixee-cli
that referenced
this pull request
Aug 6, 2026
The documented Homebrew install installs nothing. From a clean machine: ``` $ brew tap pixee/pixee ==> Tapping pixee/pixee Cloning into '/opt/homebrew/Library/Taps/pixee/homebrew-pixee'... Tapped 1 formula (18 files, 54.9KB). $ brew install pixee Error: Refusing to load formula pixee/pixee/pixee from untrusted tap pixee/pixee. ``` Step one succeeds and gives no hint of a problem, so this surfaces at step two as what looks like a security error rather than a stale instruction. Two causes: 1. `pixee/homebrew-pixee` was renamed to `pixee/homebrew-tap`, so `pixee/pixee` resolves through a GitHub redirect and installs a second tap for the same repo. With both present the short name is ambiguous: `Error: Formulae found in multiple taps`. 2. Since Homebrew 6.0.0 a non-official tap must be trusted before Homebrew will load a formula from it by short name. `brew install pixee/tap/pixee` fixes both. Correct tap, and installing by fully qualified name trusts that one formula, so no `brew trust` step is needed: ``` ==> Tapping pixee/tap ==> Trusted formula pixee/tap/pixee ==> Installing pixee from pixee/tap 🍺 /opt/homebrew/Cellar/pixee/0.17.0: 4 files, 63.7MB ``` Both paths were run from a fully reset state (no binary, no taps, empty trust file) rather than reasoned about: the old instructions install nothing, the new one yields `pixee 0.17.0` from a single tap. The trust mechanics are deliberately not explained in the README. A reader installing the CLI does not need Homebrew's trust model, only a command that works, and Homebrew's own error message points anyone who needs it at `brew trust`. The customer-facing copy in pixee/docs `docs/api/cli.md` has the same two-line block and the same bug. That page is already being rewritten in pixee/docs#295, so it belongs there. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pixee, which matters when working over SSH.PIXEE_TOKEN→ stored config, which omitted the session entirely. It is now--token→ session →PIXEE_TOKEN→ stored key, and only an explicit--tokenoutranks the session. CI behavior is unchanged: a build runner has no session, so it lands on the key.pixee auth statusexample, which quoted output from two revisions ago, and adds theauthsubcommands to Common Commands, which had no entry for the group at all.Tradeoffs:
pixee/pixee-cli-private#37is green and awaiting review; this should merge after that releases, or customers will read about a flow their installed CLI does not have.