## TL;DR

This error means your Scaleway CLI has no default organization ID or default project ID configured, so any command that needs one refuses to run. Set both defaults once with `scw config set default_organization_id=[your organization ID] default_project_id=[your project ID]`, or pass them per session with the SCW_DEFAULT_ORGANIZATION_ID and SCW_DEFAULT_PROJECT_ID environment variables. You can find both IDs in the Scaleway console (IAM and organization settings).

### Verbatim error

```text
no default organization ID or project ID is set
```

## When this applies

- You ran an `scw` command and got `no default organization ID or project ID is set`.
- You set up `scw` by hand (copied keys into the config file, or are in a fresh container/CI job) and never ran the interactive `scw init` setup.
- The failing command creates or lists resources, which need an organization and usually a project to scope the API call.

## When this does NOT apply

- `default organization ID cannot be empty` during `scw config set` or client setup: that is the same missing default, but the fix below also resolves it. Fine to keep reading.
- `Invalid access key` / `unauthorized` errors: your credentials are wrong or expired, not the defaults. Regenerate the access key and secret key in the console.
- Region or zone errors (e.g. unknown zone): set `default_region` and `default_zone` instead.
- Terraform `scaleway` provider errors: those use provider arguments, not the CLI config.

## Fix

### 1. Check what is currently configured

```bash
scw config get
```

Expected output: a table of your config. If `default_organization_id` and `default_project_id` are missing or empty, that confirms the problem. Note the profile name: profiles have separate config files, so `-p prod` commands read a different config than the default profile.

### 2. Find your organization ID and project ID

In the Scaleway console, go to IAM / organization settings. The organization ID is a UUID; do not paste your email address or account name there, those are not valid. Your default project ID is shown on the Projects page. Copy both IDs.

Expected output: two UUID values, one for the organization and one for the project.

### 3. Set the defaults permanently

```bash
scw config set default_organization_id=[your organization ID] default_project_id=[your project ID]
```

The `scw config set` keys use underscores. This writes to your config file (usually under the scw config directory), so it survives new shells.

Expected output: the set succeeds silently; run `scw config get` again and both IDs now appear.

### 4. Alternative: per-session defaults via environment variables

```bash
export SCW_DEFAULT_ORGANIZATION_ID=[your organization ID]
export SCW_DEFAULT_PROJECT_ID=[your project ID]
```

Environment variables override the config file for that session, which makes them the right choice in CI jobs and Docker containers. They are unset when the shell exits, so nothing persists.

Expected output: the previously failing `scw` command now runs instead of printing the error.

### 5. Re-run the original command

Run the exact command that failed.

Expected output: the command executes (or fails on a later, unrelated error), instead of printing `no default organization ID or project ID is set`.

## Variant phrasings

### default organization ID cannot be empty
The current CLI and SDK use this wording in config validation (`scw config set` with an empty value, or client setup). Same missing default, same fix.

### no default project ID is set
Same root cause, narrowed to the project half. Setting both defaults (step 3) resolves it.

### scaleway scw no default organization ID project ID
The search phrasing external agents use for this failure. Follow the same steps.

## Why it happens

`scw` resolves the organization and project ID from three places, in this order: the value passed to the command, the `SCW_DEFAULT_ORGANIZATION_ID` / `SCW_DEFAULT_PROJECT_ID` environment variables, then the config file. A fresh install that skipped the interactive `scw init` flow has none of these set, and commands that scope API calls to an organization or project fail at config resolution before any API call happens.

## Edge cases

- Named profiles (`scw -p prod ...`) each keep their own config file. Setting defaults on the default profile does nothing for `-p prod`; run `scw -p prod config set ...` or export the env vars.
- Environment variables win over the config file. A stale `SCW_DEFAULT_ORGANIZATION_ID` exported in your shell beats what `scw config set` wrote; if the error persists after setting defaults, check `env | grep SCW_`.
- `scw config set` keys use underscores (`default_organization_id`), not dashes. The get command accepts dashes.
- `scw config destroy` deletes the whole config file including credentials. Only use it if you intend to re-run `scw init` from scratch.
- Terraform does not read this config: the `scaleway` provider needs `organization_id` and `project_id` (or the same env vars) set separately.

## Tool compatibility

Scaleway CLI v2 (`scw`); the `config get`, `config set`, and `init` namespaces. Environment variable names `SCW_DEFAULT_ORGANIZATION_ID` and `SCW_DEFAULT_PROJECT_ID` come from scaleway-sdk-go and are honored by the CLI and SDK-based tools.