Comparison with one-cli secrets manager

[HaleTom]

Problem or motivation

Users evaluating authsome alongside other CLI-based secret/credential managers (like one-cli) have no reference material to understand the strengths, weaknesses, and ideal use cases for each tool. Without a clear comparison, it's hard for potential adopters to decide which tool fits their workflow.

Proposed solution

Add a comparison document (or README section) that covers:

• Strengths of authsome vs one-cli (e.g., OAuth/PKCE flows, provider registry, device code auth, DCR)
• Strengths of one-cli vs authsome (e.g., general-purpose secrets management, multi-backend support)
• Use cases better suited for each tool — when to pick authsome vs one-cli
• Feature matrix — side-by-side comparison of supported auth flows, storage backends, encryption, CLI ergonomics, etc.

Alternatives considered

• Relying on community blog posts or word-of-mouth comparisons (fragmented, potentially outdated)
• Users manually evaluating both tools (time-consuming, no structured guidance)

Area

Documentation

Additional context

This would help with adoption by giving users a clear, honest comparison rather than forcing them to research both tools independently. A fair comparison that acknowledges each tool's strengths builds trust.

[HaleTom]

Research findings: Authsome vs OneCLI (onecli/onecli) vs Agent Vault (botiverse/agent-vault)

Note: The originally referenced One-CLI/onecli doesn't exist. The correct project is onecli/onecli — an open-source credential vault with Rust gateway, Next.js dashboard, and PostgreSQL backend.

---

When to pick each

	Authsome	OneCLI	Agent Vault
Core model	Auth-first credential broker — understands OAuth flows, token lifecycle, multi-account	Secrets-first vault — stores static credentials and injects them via proxy	File-level secret replacement — reads/writes config files with placeholder substitution
Secret delivery	HTTP proxy injects headers (no placeholder needed in config)	HTTP proxy swaps FAKE_KEY placeholder for real key	CLI overwrites entire file, replacing <agent-vault:key> placeholders with real values
OAuth support	First-class: PKCE, device code, dynamic client registration	None	None
API key support	Yes, via HTTP header injection	Yes, via FAKE_KEY swap model	Yes, via file-level placeholder substitution
Bundled providers	45 out of the box (14 OAuth2, 31 API key) — zero-config for common services	No provider concept — secrets are typed key-value pairs with host patterns	No provider concept — secrets are named keys in an encrypted vault
Custom providers	Local JSON files via authsome register ./provider.json, stored at ~/.authsome/providers/. No public registry — upstream contribution via PR	N/A	N/A
Setup	pip install authsome, runs locally, no Docker	Single Docker container (Rust gateway + Next.js + PostgreSQL)	npm install -g agent-vault, runs locally, no Docker
Agent integrations	First-class adapters for Claude Code, Codex, Cursor, etc.	Generic HTTPS proxy, no agent-specific adapters	SKILL.md for Claude Code; CLI-based for others
Config file access	Doesn't touch config files — operates at network layer	Doesn't touch config files — operates at network layer	Reads and rewrites config files directly
Non-HTTP secrets	No (HTTP/HTTPS proxy only)	No (HTTP/HTTPS proxy only)	Yes (any file-based config: .env, docker-compose.yaml, etc.)
Token refresh	Automatic — handles expiry and renewal transparently	N/A (static keys only)	N/A (static keys only)
Encryption	Local encrypted vault	AES-256-GCM at rest in PostgreSQL	AES-256-GCM vault at ~/.agent-vault/vault.json
Team/multi-user	Multi-account per provider, local-first design	Web UI for teams, policy rules (block/rate-limit), audit logs	Local-only, single user
Vault integrations	Local vault	Bitwarden and other external vaults	None

---

How secret injection actually works (three different models)

These tools take fundamentally different approaches to keeping secrets out of agent context:

1. OneCLI — placeholder swap model

1. Store real API key in the OneCLI vault via web UI
2. In your MCP server config, set the env var to FAKE_KEY
3. Point the HTTPS proxy to localhost:10255
4. OneCLI intercepts outbound requests, sees FAKE_KEY in the header, swaps it for the real credential based on host/path pattern matching

The config file contains a known placeholder; the proxy replaces it at the network boundary.

2. Authsome — header injection model (no placeholder needed)

1. Register a provider (JSON with api_url, api_key.header_name, api_key.header_prefix)
2. Store the real key via authsome login <provider> — opens a local Browser Bridge form, key stored in encrypted vault as ConnectionRecord.api_key
3. Wrap your MCP server: authsome run -- <your-mcp-command>
4. Proxy intercepts outbound HTTPS to the matching api_url host, calls resolve_credentials(), and adds the real credential header (e.g. Authorization: Bearer sk-real-key) to the request

Key distinction: Authsome does NOT do placeholder replacement. Your config files don't need any API key at all — the proxy adds the real header at the network boundary. The resolve_credentials() method in src/authsome/server/credential_service.py reads the ConnectionRecord from vault and builds headers from ApiKeyConfig (header_name + header_prefix + token value). For OAuth2 providers, it always uses Authorization: Bearer {access_token} with automatic token refresh.

3. Agent Vault — file rewrite model

1. Store secrets in the encrypted vault (~/.agent-vault/vault.json, AES-256-GCM)
2. Agent reads config files via agent-vault read <file> — returns the full file content with <agent-vault:key> placeholders and line numbers
3. Agent modifies the content as needed
4. Agent writes back via agent-vault write <file> --content '...' — replaces the entire file, substituting placeholders with real values

This is the only approach that works for non-HTTP config files (.env, docker-compose.yaml, Kubernetes manifests, etc.). The tradeoff: agent-vault write overwrites the entire file — there's no partial edit. For large files or when preserving comments/formatting matters, this can be lossy.

---

When to use which

• Authsome — OAuth flows (PKCE, device code, DCR), automatic token refresh, zero-config bundled providers, multi-account per provider, first-class agent adapters. Best for HTTP-based APIs where you want secrets to never appear in agent context.
• OneCLI — Static API keys with a web UI vault for teams, policy rules (block/rate-limit), audit logs, Bitwarden integration. Best for team environments with shared static credentials.
• Agent Vault — Non-HTTP config files (.env, docker-compose, K8s manifests), any file where you need placeholder substitution. Best when your secrets live in config files, not just HTTP headers.

Community marketplace

None of the three projects have a public provider marketplace:

• Authsome: Custom providers are local JSON files. The 45 bundled providers cover most common services (GitHub, Google, AWS, Azure, OpenAI, Anthropic, etc.). To share a provider upstream, submit a PR to agentrhq/authsome with the provider JSON and tests.
• OneCLI: No provider concept — secrets are just typed key-value pairs scoped by host/path patterns. Nothing to share.
• Agent Vault: No provider concept — secrets are named keys in a local vault. Nothing to share.

Related

Agent credential brokers in 2026: Authsome vs Agent Vault vs Clawvisor vs OneCLI — covers the broader landscape of all four open-source credential brokers.