- Base branch target (`dev`):
- Problem: Regenerating a pairing code requires manually editing `config.toml` to clear `paired_tokens` — error-prone,
undiscoverable, and harder when using non-default config paths (`ZEROCLAW_CONFIG_DIR`, workspace overrides).
- Why it matters: Web dashboard users may need to re-pair (new browser, cleared session, token rotation, shared
workstation). A one-flag solution eliminates manual config surgery.
- What changed: Added `--new-pairing` flag to `zeroclaw gateway`. When passed, it clears all stored paired tokens via
`config.save()` (respects whatever config path is active) before `PairingGuard::new()` initializes, which triggers automatic
generation of a fresh 6-digit pairing code.
- What did **not** change (scope boundary): `PairingGuard` internals, `run_gateway` signature, config schema, pairing protocol,
token format.
Closes: #1956
## Label Snapshot (required)
- Risk label: `risk: low`
- Size label: `size: XS`
- Scope labels: `gateway`
- Module labels: `gateway: pairing`
- If any auto-label is incorrect: N/A
## Change Metadata
- Change type: `feature`
- Primary scope: `gateway`
## Linked Issue
- Closes #<issue_number>
## Supersede Attribution
N/A
## Validation Evidence (required)
```bash
cargo fmt --all -- --check # pass
cargo clippy --all-targets -- -D warnings # zero new warnings
cargo build # pass
Manual verification:
zeroclaw gateway --help # --new-pairing flag visible in help text
zeroclaw gateway --new-pairing # prints "Cleared paired tokens" log, displays fresh 6-digit code
# config.toml: paired_tokens = [] persisted
- Evidence provided: build pass, manual CLI test
- If any command is intentionally skipped: cargo test — no new logic that warrants unit tests (flag wiring + existing
config.save() + existing PairingGuard::new() empty-token path)
Security Impact (required)
- New permissions/capabilities? No
- New external network calls? No
- Secrets/tokens handling changed? No — uses existing config.save() and PairingGuard::new() code paths
- File system access scope changed? No
- Note: --new-pairing intentionally invalidates all existing sessions. This is the expected behavior for credential rotation.
Privacy and Data Hygiene (required)
- Data-hygiene status: pass
- Redaction/anonymization notes: N/A
- Neutral wording confirmation: Yes
Compatibility / Migration
- Backward compatible? Yes — flag is opt-in, default false
- Config/env changes? No
- Migration needed? No
i18n Follow-Through
- i18n follow-through triggered? No
Human Verification (required)
- Verified scenarios: --new-pairing clears tokens and displays fresh code; omitting the flag preserves existing tokens as
before
- Edge cases checked: flag with no prior tokens (still works, generates code as normal)
- What was not verified: non-default config paths (logic delegates to existing config.save() which already handles
ZEROCLAW_CONFIG_DIR and workspace overrides)
Side Effects / Blast Radius (required)
- Affected subsystems/workflows: Gateway startup path only, when --new-pairing is explicitly passed
- Potential unintended effects: None — existing behavior unchanged without the flag
- Guardrails: INFO log line confirms token clearing; pairing code display confirms new code generated
Agent Collaboration Notes (recommended)
- Agent tools used: Claude Code
- Verification focus: compilation, flag wiring, config persistence path-independence
- Confirmation: naming + architecture boundaries followed
Rollback Plan (required)
- Fast rollback: git revert <commit>
- Feature flags or config toggles: N/A — CLI flag, no persistent state change beyond what user requested
- Observable failure symptoms: --new-pairing flag unrecognized (would mean revert succeeded)
Risks and Mitigations
- Risk: User accidentally passes --new-pairing and invalidates all active sessions
- Mitigation: Flag is explicit and long-form only (no short alias), INFO log clearly states what happened
Implements self-update functionality that downloads the latest release
from GitHub and replaces the current binary.
Features:
- `zeroclaw update` - downloads and installs latest version
- `zeroclaw update --check` - checks for updates without installing
- `zeroclaw update --force` - forces update even if already latest
- Cross-platform support (Linux, macOS, Windows)
- Atomic binary replacement on Unix, rename+copy on Windows
- Platform-specific archive handling (.tar.gz on Unix, .zip on Windows)
Closes#1352
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace default UTC timer with ChronoLocal::rfc_3339() so daemon and
CLI log lines display the operator's local time, making correlation
with external events easier.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Fixes two related issues with Gemini OAuth:
1. CLI command `zeroclaw auth refresh --provider gemini` was hardcoded to
only support OpenAI Codex, making manual token refresh impossible for
Gemini profiles. Extended the CLI handler to support both providers.
2. GeminiProvider.build_generate_content_request() was missing bearer token
for ManagedOAuth auth type. The method applied OAuth bearer token only
for CLI OAuth (GeminiAuth::OAuthToken), but not for managed profiles
(GeminiAuth::ManagedOAuth), causing 401 Unauthorized errors even after
successful token refresh.
Changes:
- src/main.rs: AuthCommands::Refresh now handles both openai-codex and
gemini providers via pattern match
- src/providers/gemini.rs: Extended OAuth bearer token handling to include
GeminiAuth::ManagedOAuth case (line 837)
Verification:
- Manual test: zeroclaw auth refresh --provider gemini --profile second
- E2E test: echo "hello" | zeroclaw agent --provider gemini --model gemini-2.5-pro
- Unit tests: cargo test providers::gemini (38 passed)
Risk: Low (isolated auth flow changes, no API contract changes)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Replace hardcoded `version = "0.1.0"` in clap command attribute with
`version` (no value), which makes clap read from CARGO_PKG_VERSION
automatically. This ensures `zeroclaw -V` always reflects the version
defined in Cargo.toml.
Daemon heartbeat and cron tasks called agent::run() which hardcoded
channel_name as "cli" and always created an ApprovalManager, causing
[Y]es / [N]o / [A]lways stdin prompts on the unattended daemon terminal.
Add interactive parameter to agent::run(): CLI passes true (preserving
approval flow), daemon/cron pass false (no ApprovalManager, channel
marked as "daemon").
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Thread Option<&HookRunner> into run_tool_call_loop with hook fire points
for LLM input, before/after tool calls. Add hooks field to
ChannelRuntimeContext for message received/sending interception.
Build HookRunner from config in run_gateway and fire gateway_start.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ZeroClaw's memory system powers context injection, auto-save, and long-term agent identity — but until now users had
**zero visibility** into what's stored. No way to list, inspect, audit, or clean up memory outside the agent loop.
`zeroclaw memory` closes this gap with four subcommands:
- **`list`** — browse all entries with `--category`/`--session` filters and `--limit`/`--offset` pagination
- **`get`** — inspect a single entry by key (supports prefix match — no need to copy full UUID)
- **`stats`** — backend health, total count, per-category breakdown at a glance
- **`clear`** — batch delete by `--category`, single delete by `--key`, with confirmation prompt (`--yes` to skip)
| Before | After |
|--------|-------|
| Memory is a black box | `memory stats` shows health + distribution |
| Can't see what auto-save stored | `memory list --category conversation` |
| Can't inspect a specific entry | `memory get <key-or-prefix>` |
| Can't clean stale data without `/clear` in agent | `memory clear --category daily --yes` |
| Must enter agent loop to manage memory | Direct CLI, no LLM invocation needed |
| File | Change |
|------|--------|
| `src/memory/cli.rs` | **New** — CLI handler with list/get/stats/clear + unit tests |
| `src/memory/mod.rs` | Add `pub mod cli` |
| `src/lib.rs` | Add `MemoryCommands` public enum |
| `src/main.rs` | Add private `MemoryCommands`, `Commands::Memory` variant, match arm |
- **Lightweight backend creation**: CLI uses `create_memory_for_migration` (no embedding provider) since
list/get/stats/clear don't need vector search. Postgres handled separately.
- **Prefix matching**: Both `get` and `clear --key` fall back to prefix search when exact match fails — essential
since keys are UUIDs.
- **Confirmation by default**: All destructive operations require `dialoguer::Confirm`; `--yes` for
scripts/automation.
- **Record-style list output**: Full key displayed (no truncation), one entry per block — keys are too long for
tabular layout.
- Add global --config-dir CLI flag that sets ZEROCLAW_CONFIG_DIR env
- Add ZEROCLAW_CONFIG_DIR override in config resolution (takes precedence)
- Update OpenRC script to use --config-dir and set env vars for config/workspace
- Prefer /usr/local/bin/zeroclaw for OpenRC executable
- Create /etc/zeroclaw/workspace directory with correct ownership on install
- Update docs to reflect --service-init flag order (service-level before subcommand)
- Add InitSystem enum with auto-detection (systemd/OpenRC)
- Add --service-init CLI flag to override init system detection
- Generate OpenRC init script with security hardening:
- Runs as zeroclaw:zeroclaw user
- umask 027 for file permissions
- Logs to /var/log/zeroclaw/
- Depends on net and firewall
- Require root for OpenRC install with clear error message
- Warn if binary is in home directory
- Add OpenRC auto-restart support in channels module
- Document OpenRC setup in README and network-deployment.md
Non-goals:
- No changes to systemd behavior
- No user-level OpenRC services
- No other init systems (SysV, runit, s6)
Security: OpenRC install requires root, validates user, creates
directories with proper permissions
Add a custom value_parser for the --temperature CLI argument to enforce
the documented 0.0-2.0 range at parse time. Previously, the comment
stated the valid range but clap did not reject out-of-range values,
allowing invalid temperatures to propagate to provider API calls.
- Add parse_temperature() validator that rejects values outside 0.0..=2.0
- Wire it into the Agent subcommand's temperature arg via value_parser
Addresses API surface audit §2.3 (CLI argument range validation).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add a `config schema` subcommand that dumps the full configuration
schema as JSON Schema (draft 2020-12) to stdout. This enables
downstream consumers (like PankoAgent) to programmatically validate
configs, generate forms, and stay in sync with zeroclaw's evolving
config surface without hand-maintaining copies of the schema.
- Add schemars 1.2 dependency and derive JsonSchema on all config
structs/enums (schema.rs, policy.rs, email_channel.rs)
- Add `Config` subcommand group with `Schema` sub-command
- Output is valid JSON Schema with $defs for all 56 config types
Add Update variant to CronCommands in both main.rs and lib.rs, with
handler in cron/mod.rs that constructs a CronJobPatch and calls
update_job(). Includes security policy check for command changes.
Fixes from review feedback:
- --tz alone now correctly updates timezone (fetches existing schedule)
- --expression alone preserves existing timezone instead of clearing it
- All-None patch (no flags) now returns an error
- Output uses consistent emoji prefix
Tests exercise handle_command directly to cover schedule construction.
Closes#809
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
