v0.7.0

Summary

• Added encrypted session artifacts at rest, including .crypto-manifest recovery metadata, stricter integrity handling, and fail-closed recovery behavior for encrypted session state.
• Added named execution routes plus session-level route precedence so requests, sessions, agents, and defaults can target reusable backend definitions instead of repeating raw provider:model strings everywhere.
• Unified shared OAuth onboarding and auth-profile persistence for Codex and Gemini flows, tightening encrypted token storage and reducing provider-specific setup divergence.
• Hardened the shared WASM plugin engine/bootstrap path, including shared-engine first-use coordination and cached compiled component reuse.
• Fixed Signal explicit read receipts so the durable append boundary owns receipt completion and the normal success path sends the read receipt before typing begins.

Breaking Changes

• If sessions.encryption.mode rewrites plaintext sessions into encrypted artifacts (for example if_password with CARAPACE_CONFIG_PASSWORD present, or required), older releases such as v0.6.0 cannot transparently read that rewritten session store. Rolling back after those writes requires the pre-upgrade backup or a fresh session store.
• The new routes map and route selector fields are additive in v0.7.0, but they are not understood by v0.6.0. If you adopt named routes and later roll back, restore the pre-upgrade config or convert those route references back to direct model strings first.

Migration Steps

• Before upgrading, create a backup:
  • cara backup --output ./carapace-backup-v0.6.x.tar.gz
• If you keep direct model strings and leave session encryption off or unchanged, a routine v0.6.0 -> v0.7.0 upgrade does not require an immediate config migration.
• If you plan to enable encrypted sessions, set and retain CARAPACE_CONFIG_PASSWORD before first v0.7.0 start, and keep backing up the full state directory so .crypto-manifest is preserved with the rest of the session store.
  • There is still no in-place session-encryption rekey/password-change flow. If you later need to change CARAPACE_CONFIG_PASSWORD, export or delete the encrypted sessions and start with a fresh encrypted session store.
  • If you still have legacy plaintext sessions that will be touched and migrated on v0.7.0, keep CARAPACE_SERVER_SECRET stable during that migration window; rotating it too early can invalidate old integrity sidecars before those sessions are rewritten.
• If you want to adopt named routes, define them under the top-level routes map and then point agents/defaults at route names instead of editing every model field by hand.
  • Example:
    • routes.fast.model: "gemini:gemini-2.0-flash"
    • agents.defaults.route: "fast"
• After upgrade, verify the install:
  • cara verify --outcome auto
  • cara verify --outcome autonomy
• If you use Signal with explicit read receipts enabled, validate one real direct-message thread after upgrade so the expected read -> typing -> reply ordering is confirmed in your deployment.

Rollback Steps

• Reinstall the previous known-good binary, for example v0.6.0.
• If v0.7.0 has rewritten any sessions into encrypted form, restore the backup you created before upgrade:
  • cara restore ./carapace-backup-v0.6.x.tar.gz
• If you adopted routes or new route config fields on v0.7.0, revert those config changes or restore the pre-upgrade config backup before starting v0.6.0.
• Re-run:
  • cara status --port 18789
  • cara verify --outcome auto --port 18789
  • cara verify --outcome autonomy --port 18789

Security

• Session history, metadata, and archives can now encrypt at rest under the session-encryption policy, with recovery gated on the paired .crypto-manifest instead of trusting the password alone.
• Session integrity handling is tightened around encrypted recovery, manifest backfill, and mixed plaintext/encrypted migration paths so corruption fails closed more consistently.
• Shared OAuth onboarding for Codex and Gemini now runs through the common encrypted auth-profile path rather than duplicating provider-specific token persistence behavior.
• Shared plugin engine/bootstrap handling is hardened around startup ownership, component compilation reuse, and first-use coordination.
• No new public advisories are introduced by this release.

Verification

• Verify published artifacts and Sigstore bundles:
  • RELEASE_TAG=v0.7.0 ./scripts/smoke/verify-release-artifacts.sh
• After upgrading, verify runtime behavior:
  • cara verify --outcome auto
  • cara verify --outcome autonomy
• If you enable encrypted sessions, unlock at least one existing session after restart and confirm its history loads with the same CARAPACE_CONFIG_PASSWORD.
• If you use Signal read receipts, validate one real direct-message thread against the Signal smoke playbook after the release build is installed.

Known Caveats

• There is still no in-place session-encryption rekey/password-change flow. Changing CARAPACE_CONFIG_PASSWORD after encrypted session artifacts already exist requires exporting or deleting those sessions and starting from a fresh encrypted store.
• During touch-time migration of older plaintext sessions into encrypted form, keep a stable CARAPACE_SERVER_SECRET until the legacy sessions you care about have been opened or migrated; rotating the legacy integrity secret too early can invalidate old sidecars.
• Signal explicit read receipts still apply only to supported direct-message text ingests. Unsupported Signal group or non-text messages remain unread when explicit read receipts are enabled because Carapace does not ingest them yet.
• Signal runtime wiring is implemented, but published live smoke evidence is still narrower than the core CLI/control paths; keep using the documented channel smoke playbook for release validation.