# Adopting a Deployment the CLI Did Not Create | Changelog

Source: https://wraps.dev/changelog/adopting-a-deployment-the-cli-did-not-create

![Wraps Logo](https://wraps.dev/wraps-light-logo.png)![Wraps Logo](https://wraps.dev/wraps-dark-logo.png)

](https://wraps.dev/)

[](https://github.com/wraps-team/wraps)[Log in](https://app.wraps.dev/auth?mode=signin)[Sign up](https://app.wraps.dev/auth?mode=signup)

Toggle menu

[← All changes](https://wraps.dev/changelog)

CLIAugust 2026

### Adopting a Deployment the CLI Did Not Create

-   `wraps platform connect` and `wraps platform update-role` adopt an existing deployment. A CloudFormation quick-create customer has no local state file and no S3 state bucket to sync from, so both commands dead-ended — including on the documented repair path for a broken IAM trust policy. Registration is idempotent on the External ID, so adoption registers the account and repairs the trust policy without deploying anything
-   `wraps doctor` reports `wraps-*` resources it finds in AWS with no local connection record, instead of announcing no email deployment. That is what a CloudFormation-first connection looks like, and what a second machine looks like
-   Fix: `wraps update` never resolved a release. It matched tags beginning `cli@`; every release is tagged `cli-v`. Standalone installs only ever saw “Could not determine latest version from GitHub releases”
-   Fix: one telemetry event per invocation. `wraps permissions` emitted three and `wraps email domains add` emitted two names a millisecond apart, which inflated the reported failure rate and split one command across two names
-   Fix: a failure thrown before the handler runs is named by its third positional, so a failing `email domains verify` is distinguishable from a failing `email domains remove` rather than collapsing into `email:domains`

CLI v3.5.3