# Troubleshoot Import and Apply Errors > Fix common Rudder CLI errors when you import workspace resources or apply changes to a project. This guide covers common validation and error scenarios when you import workspace resources into a CLI project or run `apply` afterward. ## Project has changes to be synced {#unsynced-changes-in-project} The `import workspace` command fails with the following error: ```text Error: import not allowed as project has changes to be synced ``` **What it means**: Before it imports anything, Rudder CLI compares your local project with the resources in the workspace that are already CLI-managed. The import runs only when the two match, that is, when `apply` would have nothing to do. Any difference blocks it: - Resources in your project that don't exist in the workspace yet - Resources whose settings in your project differ from the workspace - CLI-managed resources in the workspace that your project doesn't contain Differences in secret values alone don't block the import. **Common causes** - **The workspace already has resources managed by another CLI project.** This is the usual cause when you run the import from a new or empty directory. Your project contains none of those resources, so they count as pending deletions. The import never re-imports resources that a project already manages, so there's no way to import them into a second project. - **Your project has changes you haven't applied yet**, or someone changed CLI-managed resources outside Rudder CLI. - **Your specs use `{{ .VAR }}` references and you didn't pass `--var-file`.** Without the var file, `import workspace` can't resolve those references when it reads the project, so the affected fields read as changes. Rudder CLI v0.26.0 and later accept `--var-file` on `import workspace`. Pass the same var file you use with `apply`: ```bash rudder-cli import workspace -l --var-file ./secrets.vars.yaml ``` On v0.25.1 and earlier, `import workspace` has no `--var-file` flag. Upgrade Rudder CLI. **Warning:** Don't run `apply` just to clear this error. If you run it from an empty or partial project, `apply` **deletes** every CLI-managed resource in the workspace that the project doesn't contain. **Fix**: 1. See what differs. A dry run shows the plan without changing anything: ```bash rudder-cli apply -l --dry-run ``` Resources under **Removed resources** are CLI-managed in the workspace but missing from your project. `apply` would delete them. 2. If **Removed resources** lists resources that this project didn't create, another CLI project owns them. Find the Git repository that holds that project and run `import workspace` from there, so a single project manages the whole workspace. See [One project per workspace](https://www.rudderstack.com/docs/rudder-cli/import-resources/#one-project-per-workspace). If you can't find that project, contact RudderStack support before you run `apply`. 3. If the plan shows only changes you intend to make, such as specs you added or edited in this project, apply them and then run `import workspace` again. ## Imported directory already exists If an `imported` directory already exists in your project, the `import workspace` command will fail with the following error: ```text Error: directory for import: my-project/imported already exists ``` **Fix**: Move anything you need out of `imported/`, delete the `imported` directory, and run `import workspace` again. ## Import fails with "file exists" for transformation code {#transformation-library-name-collision} The `import workspace` command fails with an error like: ```text Error: writing files for formattable entities: writing my-project/imported/transformations/javascript/.js: opening file ... file exists ``` **Cause**: A transformation and a transformation library in the workspace use the same language and have the same name. Names that differ only in case, spaces, or punctuation, such as `My Utils` and `my-utils`, count as the same. Import tries to write both code files to the same path. This is a known issue in Rudder CLI v0.25.1 and earlier. **Fix**: Upgrade to a Rudder CLI release that includes the import file-name dedupe fix, where import renames the second file automatically. On v0.25.1 and earlier: 1. In the RudderStack dashboard, rename the transformation or the library so the names differ. If you rename the library, make sure its import name, which transformation code uses to import it, doesn't change. 2. Delete the partially written `imported` directory. 3. Run `import workspace` again. ## Import fails for a specific resource When `import workspace` or a resource-specific `import` fails: - Confirm the workspace still contains the `remote_id` you're importing - Confirm your token includes the [required permissions](https://www.rudderstack.com/docs/rudder-cli/import-resources/#required-permissions) for that resource type - Make sure the `local_id` doesn't conflict with an existing CLI-managed resource ## Apply fails after import When `apply` fails right after an import: - Check that every generated YAML file is present and valid - For SQL models you imported with `--sql-location`, keep the YAML and the referenced `.sql` file on the paths Rudder CLI expects - Confirm you're logged in and the token can reach the workspace - Confirm that no manual changes were made to the resource in the RudderStack dashboard after import — if changes were made outside Rudder CLI, you will be prompted to reconcile them ## Resource deleted from dashboard after import {#resource-deleted-from-dashboard-before-apply} If you delete an imported resource in the dashboard or through the API, `apply` fails with a not-found error for that resource on every run. See [I deleted an imported resource in the dashboard. Why does `apply` keep failing?](https://www.rudderstack.com/docs/rudder-cli/faq/#deleted-imported-resource) for the fix.