mirror of
https://github.com/agentclientprotocol/claude-agent-acp.git
synced 2026-10-27 04:30:59 +00:00
966be7abe6
## What ACP `logout` cleared `providerConfig` and the gateway credentials but left live queries running. Provider and gateway routing is baked into each query's env, so open sessions kept using the old route after logout. `logout` now recreates every live session through the same path as `providers/disable` (`enqueueProviderUpdate`), but only when a provider or gateway override was active. It waits for active turns, then resumes each session under its id with native routing. This also runs when `claude auth logout` fails, because the override is already cleared by then. A plain CLI-login logout does not touch live sessions: the running CLI picks up the logout by itself. ## Behavior change With an override active, `logout` now waits for running turns before it returns, like `providers/disable`. Under `--hide-claude-auth`, a session that cannot be recreated signed out is dropped, as with `providers/disable`.
57 lines
2.1 KiB
Markdown
57 lines
2.1 KiB
Markdown
# Agent guide
|
|
|
|
An ACP-compatible coding agent powered by the Claude Agent SDK. Source in `src/`,
|
|
TypeScript, ESM, Node >= 22.
|
|
|
|
## Commands
|
|
|
|
```sh
|
|
npm run build # tsc
|
|
npm run test:run # vitest, single pass
|
|
npm run check # eslint + prettier --check
|
|
npm run lint:fix # eslint --fix
|
|
npm run format # prettier --write
|
|
```
|
|
|
|
CI runs `format:check`, `lint`, `build` and `test:run`. Run `npm run check` before
|
|
opening a PR.
|
|
|
|
## Code comments
|
|
|
|
Keep comments straightforward, concise, and concrete. Say what the code does and
|
|
why, in plain terms: name the actual state, call, or failure involved instead of
|
|
alluding to it. Prefer a short concrete example over an abstract description.
|
|
Don't use vague phrases like "keeps it honest" or "the residual case" that make
|
|
the reader reconstruct the meaning.
|
|
|
|
## Pull requests
|
|
|
|
Squash merges use the PR title as the commit subject, and release-please parses it
|
|
to compute the next version. Titles must be conventional commits using one of:
|
|
`feat`, `fix`, `perf`, `revert`, `docs`, `style`, `chore`, `refactor`, `test`,
|
|
`build`, `ci`. `conventional-prs.yml` rejects anything else.
|
|
|
|
The title also decides the release: `feat:` bumps the minor, `fix:`/`perf:` the
|
|
patch, and `chore:`/`ci:`/`test:` and friends do not release at all.
|
|
|
|
## Releasing
|
|
|
|
Stable releases are fully automated by release-please. There is no manual release
|
|
workflow, and the version is never chosen by hand — it follows from the commit
|
|
history.
|
|
|
|
```sh
|
|
npm run release:preflight # verifies it is safe to release, prints the PR and version
|
|
gh pr merge <pr-number> --squash
|
|
```
|
|
|
|
The preflight is the guard-list as code; if it exits non-zero, follow what it
|
|
prints rather than merging.
|
|
|
|
Every _other_ push to `main` publishes a preview to npm — `0.73.1-preview.4` and
|
|
so on — under the `preview` dist-tag, tags the commit it came from, and updates
|
|
the agent registry the same way a release does. Only `latest` is reserved for
|
|
real releases. So anything merged to `main` is published within minutes; there is
|
|
no staging branch. Full runbook, including how to recover a stalled release:
|
|
[`docs/RELEASES.md`](docs/RELEASES.md).
|