reply-cli: profile management, team context & raw api passthrough

[vigubikReply]

Summary

Builds out the reply CLI beyond bare auth: full profile management, team context + a team command, and a raw api passthrough that already reaches the entire v3 API. Covers REPLY-51354, REPLY-51325, REPLY-51257, REPLY-51258, REPLY-51259.

What's included

REPLY-51354 — profile management

• profile rename <old> <new> (moves the stored credential with the def), profile delete <name> (rm; confirm-by-default, --yes to skip), profile show [name] (redacted; authorization shown in precedence order), profile unset <name> <field> (clear authority/api_base/team-id).
• URL validation on --authority/--api-base (http/https only).

REPLY-51325 — client identification

• Sends User-Agent: reply-cli/<version> on API requests (captured by APM as user_agent.original), so API-key traffic is identifiable even without an OAuth client_id.

REPLY-51257 — team/acting-user context

• Profile api_base is the host (no /v3); the version prefix lives in the request path. X-TEAM-ID precedence --team-id > REPLY_TEAM_ID > profile team_id; org-key acting user via --user-id / --user-email.

REPLY-51258 — team command + conflict guidance

• team list / current (pinned + effective-from-whoami) / use <id> (verified) / clear, editing the current profile's team_id (no separate team state).
• Discovery via /v3/whoami/team-users, resilient to the TEAM_REQUIRED 403 (same teams[]); falls back to the single whoami team when the endpoint is organization-only.
• On a workload team/user-resolution conflict, prints a tailored fix + team list to stderr (aligns with backend contract in reply-team/replyapp#1704).

REPLY-51259 — reply api raw passthrough

• reply api <path> [--method] [--body] → {code, data}; GET by default, POST when --body (inline / @file / - stdin). Request URL is literally api_base + path (slash-safe join) — no version-specific code.
• --verbose prints a curl-style request/response trace to stderr with Authorization redacted; stdout stays clean JSON (pipe-safe).

Docs & help

• Worked Examples: blocks + clarity notes on every non-trivial command; README updated (intro surfaces reply api, Teams/Profiles/Raw-API sections, env-var table).

Testing

• 234 unit/integration tests pass (npm test); fully offline (mocked fetch, temp config/credential store).
• Verified against dev end-to-end: api /v3/whoami (and --verbose, redacted) → 200; team list/current/use/clear for a personal account; profile rename/delete/show/unset.
• The team-conflict guidance path is unit-tested now; full integration depends on reply-team/replyapp#1704 reaching dev.

Notes

• No breaking changes to existing auth commands.
• Backend dependency: the TEAM_* / USER_* problem+json contract ships in reply-team/replyapp#1704.

🤖 Generated with Claude Code

[ArtemKosolap]

Code Review — profile management, team context & raw api passthrough

Overview

Substantial, well-structured feature PR (+1886/−44, 18 files) extending the reply CLI with:

• Profile management: profile rename/delete/show/unset with URL validation.
• team command: list/current/use/clear, editing the current profile's team_id, with resilient team discovery (/v3/whoami/team-users → TEAM_REQUIRED body → single-whoami fallback).
• reply api raw passthrough: literal api_base + path, method inference, @file/-/inline body, --verbose trace with credential redaction, {code,data} output.
• Client identification: User-Agent: reply-cli/<version> on all requests.
• A repositioning of api_base to be host-only (the /v3 prefix moves into request paths).

Verification: tsc --noEmit clean; vitest run → 231 passed / 3 skipped. New code is well-covered by focused unit tests with injected deps (stdin, confirm prompt, credential store).

Strengths

• Clean separation of concerns: config-only mutations in profile.ts (rename/delete/unset_profile_def) vs. credential-store orchestration in the command layer. The handle_rename ordering (guard target → read → rename def → move credential, "orphan not destroy" on partial failure) is exactly the right instinct for a two-store operation without a transaction.
• Secret hygiene is careful and tested: request_raw pre-redacts Authorization in its request view so the raw token never leaves the transport; --verbose additionally redacts cookies; profile show reuses describe_status (no refresh, no write) and has explicit "never leaks token/key" tests.
• Consistent conventions: matches the codebase's snake_case locals, UsageError/RuntimeError with code/hint, stdout-data/stderr-status split, and injectable-deps testing style.
• /v3 path migration is applied consistently across auth, teams, team, and api (no leftover un-prefixed endpoints).

Issues & risks (by severity)

1. api_base semantics change is a breaking change for existing custom profiles (Medium).
EMBEDDED.api_base moved from https://api.reply.io/v3 → https://api.reply.io, and all paths now carry /v3. Any user who followed the previous docs and stored api_base: "https://api.dev.reply.io/v3" will now hit …/v3/v3/whoami → 404, since join_url just concatenates. There is no migration or normalization, and the prod default is safe, but the PR body's "No breaking changes to existing auth commands" doesn't hold for hand-authored dev/staging profiles (the old help text and tests confirm /v3-in-api_base was the documented convention).

• Suggestion: strip a trailing /v3 (or /v[0-9]+) from api_base in resolve_profile, or detect /v3/v3 in join_url, or at minimum add a CHANGELOG/upgrade note. profile show marking inherited-vs-explicit helps users self-diagnose, but silent 404s are a rough landing.

2. request_raw retries non-idempotent methods on transient statuses (Medium-Low).
request_raw retries [429,500,502,503,504] up to 3× regardless of method. reply api … --body @c.json is a POST, and the docs actively promote it. A POST that created a resource but returned 500 would be retried and can double-create. (429/502/503/504 are generally safe to retry; 500 after a mutation is the dangerous case.)

• Suggestion: restrict body-bearing/POST/PATCH retries to clearly-safe statuses (e.g. 429/503), or only retry idempotent methods, or document that mutations may be retried. request had the same behavior but was only ever used for GET /whoami, so request_raw is where this first becomes a real exposure.

3. handle_team_current collapses all errors into "failed to retrieve" (Low).
The catch treats a 401/invalid-credential the same as an offline network blip. A logged-out user sees failed to retrieve (…) rather than a clear "not logged in." Acceptable for a best-effort read, but a 401 could be special-cased for a better hint.

4. read_all_stdin via fs.readFileSync(0) (Low).
Correctly wrapped in try/catch (→ '' → clean UsageError). One rough edge: reply api /x --body - run interactively (no pipe) on a TTY will block on the read rather than erroring fast. Minor; worth a note that - expects piped input.

Style / maintainability (nits)

• Boilerplate duplication: Global_opts, read_globals, wants_json, print_opts are now copy-pasted across api.ts, team.ts, and profile.ts (with slightly different field sets). Consider a shared helper to prevent drift as more commands land.
• Double validation of clearable fields: CLEARABLE_INPUT/map_clearable in the command layer and CLEARABLE_FIELDS in unset_profile_field. Fine as defense-in-depth, but the command-layer map already guarantees a valid Clearable_field, so the core check is effectively unreachable — worth a comment saying so.
• Consistency: handle_team_current uses create_client().get('/v3/whoami') while the rest of the new code uses request_raw. Harmless, but two ways to reach /whoami.

Test coverage

Strong and idiomatic: slash-safe join, request_raw (2xx/4xx/retry/network), redaction, method inference, body parsing (@file/-/inline/invalid), rename/delete/unset edge cases (default-slot refusal, current-repointing, idempotent no-op), team resolution incl. the org-only fallback, and team_error_guidance per code. Gaps worth adding: a test asserting request_raw retry behavior for a POST (documents the intended idempotency decision from #2), and an integration-style test that an existing /v3 api_base config doesn't double up (would pin down #1).

Security

No concerns beyond the above. Credential redaction is enforced at the transport boundary and unit-tested against a literal secret; --user-id/--user-email remain flag-only; URL validation rejects non-http(s) schemes (file://, ftp:// tested). --verbose prints request headers + response headers only (not the response body) to stderr, keeping stdout pipe-clean.

Verdict: High-quality, ships clean (types + tests green). Recommend treating #1 as clarify-before-merge (add normalization/migration or correct the "no breaking changes" claim) and considering #2 given the raw-api POST guidance; the rest are good follow-ups.

🤖 Generated with Claude Code