Skip to main content
naive projects use persists active_project_id in ~/.naive/config.json (mode 0600) and validates the id before writing it, so a typo fails once here instead of 404-ing every later command. Every request then carries it as the X-Naive-Project-Id header.

​
Selecting a project for one command

--project <project_id> is a global flag — it works on any command and does not touch the persisted selection:
Resolution order: --project, then active_project_id from the config file, then the API key’s pinned project, then the organization’s default project.

​
Together with a child project

A child project (a tenant user) is addressed inside a project, so naive use sets both:
Every organization has a default project, and every account kit, child project and resource that existed before projects did was backfilled into it. With no project selected the CLI behaves exactly as it did — this whole page is opt-in. See Projects.

​
Archiving vs deleting

naive projects delete refuses while the project still holds account kits or child projects, rather than cascading through an organization’s data behind one verb. Move or delete those first. The default project can never be deleted. naive projects update <project_id> --archive is the answer when you want to retire a project you cannot empty: the rows stay, and any request that selects it is refused 403 project_archived. --activate undoes it. The default project cannot be archived — every un-projected request resolves to it. The slug is immutable. It is the handle other systems address the project by, so --name changes the display name alone.