Dark-Alex-17/coyote
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

docs: Fixed typo in Clients documentation

Dark-Alex-17
2026-07-20 14:34:43 -06:00
parent 9e1fb33729
commit 25824df70c
1 changed files with 20 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Clients.md
+20 -20
@@ -134,6 +134,17 @@ temporary localhost server to capture the callback automatically (e.g. Gemini, O
code back into the terminal (e.g. Claude). Coyote stores the tokens in `<coyote_cache_dir>/coyote/oauth` and automatically refreshes
them when they expire.
**Step 3: Use normally**
Once authenticated, the client works like any other. Coyote uses the stored OAuth tokens automatically:
```sh
coyote -m my-claude-oauth:claude-sonnet-4-20250514 "Hello!"
```
> **Note:** You can have multiple clients for the same provider. For example: you can have one with an API key and
> another with OAuth. Use the `name` field to distinguish them.
### OpenAI OAuth Note
OpenAI OAuth requires a **ChatGPT Plus or Pro subscription**. It uses the shared Codex CLI OAuth app registered with
@@ -179,7 +190,7 @@ Simply click the `Advanced` link and click `Go to Coyote (unsafe)` to continue t
### xAI OAuth Note
xAI OAuth requires a **SuperGrok** or **X Premium+** subscription. Coyote ships with the required OAuth endpoints and
client ID bundled in `models.yaml`, so you can enable OAuth by just adding `auth: oauth` to your xAI client entry — no
client ID bundled in `models.yaml`, so you can enable OAuth by just adding `auth: oauth` to your xAI client entry. No
additional endpoints or app registration needed.
When authenticating, Coyote starts a localhost server on port **56121** to capture the OAuth callback automatically.
@@ -187,7 +198,7 @@ This port matches what xAI's OAuth app expects and cannot be changed. Make sure
`--authenticate`/`.authenticate`.
If the authorization succeeds but the token exchange returns 403, that indicates your account does not have a valid
SuperGrok / X Premium+ subscription — not a Coyote configuration error.
SuperGrok / X Premium+ subscription. This is not a Coyote configuration error.
Example configuration:
@@ -205,13 +216,13 @@ For any provider that speaks the OpenAI API shape, you can enable OAuth on an `o
OAuth configuration in two layers:
1. **Bundled defaults** in `models.yaml` under `provider: <name>` (Coyote ships defaults for providers like xAI).
2. **Inline overrides** in your `config.yaml` under `clients[i].oauth` — you can either supply the whole block (for
2. **Inline overrides** in your `config.yaml` under `clients[i].oauth`. You can either supply the whole block (for
providers not shipped with Coyote) or override individual fields (e.g. to point at a corporate token endpoint).
For each optional field, the user's `config.yaml` value wins over the `models.yaml` default. If neither source provides
a required field (`client_id`, `token_url`), Coyote will bail with a clear error when you attempt to authenticate.
**Example — inline OAuth for a private gateway:**
**Example: inline OAuth for a private gateway:**
```yaml
clients:
@@ -231,41 +242,30 @@ clients:
Coyote ships OAuth defaults for the following providers, so you only need `auth: oauth` in your config:
* **xAI** — SuperGrok / X Premium+ subscribers
* **xAI:** SuperGrok / X Premium+ subscribers
To bundle defaults for additional providers locally, edit your `models.yaml` (see [Local Models Override](#local-models-override))
and add an `oauth:` block under the provider entry.
### client_credentials Flow
For headless machine-to-machine (M2M) authentication — no browser, no user interaction — set `flow: client_credentials`
in your `oauth` block. Coyote will POST directly to the token endpoint with `client_id` and `client_secret` and cache
For headless machine-to-machine (M2M) authentication (i.e. no browser, no user interaction), set `flow: client_credentials`
in your `oauth` block. Coyote will `POST` directly to the token endpoint with `client_id` and `client_secret` and cache
the returned access token.
RFC 6749 §4.4.3 forbids refresh tokens for the client credentials flow, so when the token expires Coyote silently
RFC 6749 forbids refresh tokens for the client credentials flow, so when the token expires Coyote silently
re-runs the client credentials exchange (still no browser). This makes it suitable for CI, servers, and other
non-interactive environments.
### Known Limitation: Token Namespacing
OAuth tokens are stored on disk at `~/.cache/coyote/oauth/{client_name}_oauth_tokens.json`, keyed by the client's `name`
field only (not by provider type). Two clients with the same `name` — even if they use different provider types — will
field only (not by provider type). Two clients with the same `name`, even if they use different provider types, will
overwrite each other's tokens.
To prevent accidental collisions, Coyote now rejects configuration files with duplicate `name` values across all
`clients[]` entries at load time. Fixing the underlying single-namespace layout is future work.
**Step 3: Use normally**
Once authenticated, the client works like any other. Coyote uses the stored OAuth tokens automatically:
```sh
coyote -m my-claude-oauth:claude-sonnet-4-20250514 "Hello!"
```
> **Note:** You can have multiple clients for the same provider. For example: you can have one with an API key and
> another with OAuth. Use the `name` field to distinguish them.
## Providers That Support OAuth
* Claude
* Gemini