neon 3.2.2 → 3.3.0

package/README.md

@@ -712,7 +712,7 @@ $ echo $?
 
 That message reports where parsing stopped and nothing more. `--data` carries whatever you put in it, and the JSON parser's own message quotes a window of the input, so echoing either would put a connection string or an API key on stdout.
 
-**One exception to "JSON on stdout".** Credentials are resolved before any command runs, so a failure in that step — an unknown `--profile` or `NEON_PROFILE`, `--api-key` and `--profile` together, or a `credentials.json` that cannot be read — prints `ERROR: …` on stderr, leaves stdout empty, and exits 1. Treat a non-zero exit with empty stdout as a credential problem and read stderr.
+**One exception to "JSON on stdout".** Credentials are resolved before any command runs, so a failure in that step — an unknown `--profile` or `NEON_PROFILE`, `--api-key` and `--profile` together, a `credentials.json` that cannot be read, or an OS keyring item that cannot be read — prints `ERROR: …` on stderr, leaves stdout empty, and exits 1. Treat a non-zero exit with empty stdout as a credential problem and read stderr.
 
 | Option | |
 | --- | --- |
@@ -822,17 +822,19 @@ Two combinations are rejected before the request: `--since` with `--start-time`,
 
 ## Profiles
 
-The CLI holds one Neon account by default. A profile adds another, and is nothing more than a pointer to a credentials file:
+The CLI holds one Neon account by default. A profile adds another, and is a pointer: a
+credentials file path, or the sentinel `"keyring"` when the secret is in the OS keyring.
 
 ```
 ~/.config/neon/
 ├── credentials.json          # this IS the DEFAULT profile
 ├── credentials.work.json     # created by `neon profile create work`
-└── profiles.json             # created only once a second profile exists
+└── profiles.json             # created once a second profile exists, or DEFAULT is keyring
 ```
 
 ```bash
-neon profile create work     # a browser sign-in, or an API key — see below
+neon profile create work              # a browser sign-in, or an API key — see below
+neon profile create work --keyring    # same, stored in the OS keyring
 neon profile list
 neon profile remove work
 ```
@@ -840,64 +842,102 @@ neon profile remove work
 ```console
 $ neon profile list
 Profiles
-┌────────┬─────────┬───────────────────────┬─────────┬────────────────┬──────┬────────────────────────┐
-│ Active │ Name    │ Account               │ Auth    │ Scope          │ File │ Credentials            │
-├────────┼─────────┼───────────────────────┼─────────┼────────────────┼──────┼────────────────────────┤
-│ *      │ DEFAULT │ me@example.com        │ oauth   │ -              │ ok   │ credentials.json       │
-├────────┼─────────┼───────────────────────┼─────────┼────────────────┼──────┼────────────────────────┤
-│        │ work    │ me@example.com        │ api key │ account        │ ok   │ credentials.work.json  │
-├────────┼─────────┼───────────────────────┼─────────┼────────────────┼──────┼────────────────────────┤
-│        │ ci      │ org-old-flower-827148 │ api key │ project proj-1 │ ok   │ credentials.ci.json    │
-└────────┴─────────┴───────────────────────┴─────────┴────────────────┴──────┴────────────────────────┘
+┌────────┬─────────┬───────────────────────┬─────────┬────────────────┬──────┬─────────┬────────────────────────┐
+│ Active │ Name    │ Account               │ Auth    │ Scope          │ File │ Storage │ Credentials            │
+├────────┼─────────┼───────────────────────┼─────────┼────────────────┼──────┼─────────┼────────────────────────┤
+│ *      │ DEFAULT │ me@example.com        │ oauth   │ -              │ ok   │ file    │ credentials.json       │
+├────────┼─────────┼───────────────────────┼─────────┼────────────────┼──────┼─────────┼────────────────────────┤
+│        │ work    │ me@example.com        │ api key │ account        │ ok   │ keyring │ keyring                │
+├────────┼─────────┼───────────────────────┼─────────┼────────────────┼──────┼─────────┼────────────────────────┤
+│        │ ci      │ org-abc-123           │ api key │ project proj-1 │ ok   │ file    │ credentials.ci.json    │
+└────────┴─────────┴───────────────────────┴─────────┴────────────────┴──────┴─────────┴────────────────────────┘
 ```
 
 `Scope` is what a key can reach; an OAuth session has none of its own, so it shows `-`. `File`
-says whether the credentials file can be read and understood — `ok`, `invalid` or `missing` —
-which is not the same as the credential still working; only using it shows that. The table shows
-the file name, `--output json` the full path.
+says whether the stored credential can be read — `ok`, `invalid` or `missing` for a file;
+`ok`, `invalid` or `unreadable` for a keyring item. A keyring get of null is `unreadable`, not missing:
+the addon cannot tell those apart. `Storage` is `file` or `keyring`, from the profile's
+pointer. The table shows the file name or `keyring`; `--output json` keeps the full path.
 
 Select one per invocation with `--profile`, or per shell with `NEON_PROFILE`. There is no `profile use` command and nothing is stored about which profile is "current", so what you type is always what runs.
 
-Entries in `profiles.json` are paths, and a path may point anywhere — which is how you adopt a directory you already have, without moving or re-authenticating anything:
+Entries in `profiles.json` are pointers — a path, or the exact string `"keyring"` — and a path may point anywhere, which is how you adopt a directory you already have without moving or re-authenticating anything:
 
 ```json
 {
   "version": 1,
   "profiles": {
-    "DEFAULT": { "credentials": "credentials.json" },
+    "DEFAULT": { "credentials": "keyring" },
     "work": { "credentials": "../neonctl-work/credentials.json" }
   }
 }
 ```
 
+An unreadable `profiles.json` fails every command that needs a profile, including a
+file-only DEFAULT. That file is the only record of where each account's credentials live,
+so the CLI will not guess past it. Fix or delete it.
+
 `neon profile remove` revokes what the profile holds — an OAuth refresh token at the
 authorization server, or an API key this CLI minted — rather than only forgetting it locally. A
 key you supplied is the exception and stays live, because nothing records its id; the command
 says so. It asks for confirmation first, which `--yes` skips; without a terminal on stdin, in
 CI or behind a pipe, it refuses rather than prompting into the void. It deletes the credentials
 file only when the CLI created it: an adopted path like the one above is unlinked and left on
-disk, and the command says so. Removing the last named profile deletes `profiles.json`,
-returning you to the single-account layout. `neon profile remove DEFAULT` signs you out.
+disk, and the command says so. A keyring profile's OS item is deleted when the store confirms
+it is gone. If it cannot, remove still resets the profile and warns that a leftover may remain
+in the OS store; it is unused once the profile is gone. Removing the last named profile
+deletes `profiles.json` unless DEFAULT itself is keyring — that entry is the only record that
+the secret is not in `credentials.json`. `neon profile remove DEFAULT` signs you out.
+
+### Where the secret is stored
+
+The default is a credentials file. A profile uses the OS keyring (macOS Keychain, Windows
+Credential Manager, Linux Secret Service) only when its `profiles.json` pointer is `"keyring"`.
+That is per profile. Reads never migrate.
+
+```bash
+neon auth --keyring                         # sign DEFAULT into the OS keyring
+neon auth --keyring --profile work          # sign work into the OS keyring
+neon profile create work --keyring          # create a named profile in the keyring
+neon profile remove work --yes              # drop a keyring profile, then create it again as a file
+```
+
+File to keyring is `neon auth --keyring` or `neon profile create … --keyring`: a new
+sign-in, then the previous credential is revoked and the owned file is deleted.
+`create` on an existing name always revokes after a successful write. `auth` revokes
+when it writes to the keyring, including a re-login that follows an existing pointer.
+`auth` that overwrites a file does not. Keyring to file is `remove`, then create or
+auth again. `create` and `auth` without `--keyring` follow an existing `"keyring"`
+pointer, so a keyring profile cannot leave the OS store until `remove` succeeds.
+
+`--api-key` and `NEON_API_KEY` skip both stores. A GitHub-release `neon-<platform>`
+binary recognizes a `"keyring"` pointer and refuses: it cannot load the OS keyring addon.
+Use the npm-installed `neon`. Older releases treat the sentinel as a relative path.
+
+A `"keyring"` pointer whose OS item cannot be read is not treated as signed-out. Commands that
+would otherwise open a browser fail: could not read the OS keyring item. Unlock it and
+retry, or run `neon auth --profile DEFAULT`. To reset the profile: `neon profile remove DEFAULT --yes`.
+A missing `credentials.json` with no `profiles.json` is still
+signed-out, and those commands start OAuth.
 
 ### A profile holds either a sign-in or an API key
 
 `neon profile create` makes a profile, and how you call it decides which kind of credential it holds. A key-backed profile is what you want for an agent, a shared machine, or anything that must never be interrupted by a browser:
 
 ```bash
-neon profile create work                            # sign in with the browser, like `neon auth`
+neon profile create work                            # sign in; replaces work if it already exists
+neon profile create work --keyring                  # same, stored in the OS keyring
 neon profile create work --api-key "$KEY"           # store a key you already have
 echo "$KEY" | neon profile create work --api-key -  # or pipe it, keeping it out of argv
 neon profile create ci --mint                       # sign in once, keep only a minted key
 neon profile create ci --mint --org-id org-abc-123  # minted for an organization
 neon profile create ci --mint --project-id proj-1   # minted for one project only
-neon profile create work --force                    # replace it, revoking what it holds now
 neon profile rotate-key work                        # mint a replacement, revoke the old one
 ```
 
-`--force` is not only a local edit: replacing a profile revokes the credential it held, so a key
-this CLI minted stops working everywhere it was pasted, and an OAuth session is signed out.
-Without `--force`, `create` refuses and names what would be revoked. To keep a working profile
-and swap only its key, use `rotate-key`.
+Replacing a profile revokes the credential it held, so a key this CLI minted stops working
+everywhere it was pasted, and an OAuth session is signed out. To keep a working profile and
+swap only its key, use `rotate-key`.
 
 `create` and `rotate-key` print the profile they wrote, so an agent needn't follow up with
 `list`. Under `--output json` that is a record, and it never carries the secret:
@@ -926,7 +966,7 @@ the key never leaves the CLI.
 { "type": "api_key", "api_key": "napi_…", "key_id": 123, "org_id": "org-…" }
 ```
 
-Nothing is carried over when a profile is replaced, so one profile can never hold two credentials — or two different accounts. The secret stays in that file and never goes into `profiles.json`, so listing profiles cannot leak one. Both files are written owner-only through a temporary file and a rename, which also repairs the permissions of a file created too permissively.
+Nothing is carried over when a profile is replaced, so one profile can never hold two credentials — or two different accounts. The secret stays in the credentials file or the OS keyring and never goes into `profiles.json`, so listing profiles cannot leak one. Files are written owner-only through a temporary file and a rename, which also repairs the permissions of a file created too permissively.
 
 `--mint` is the one to reach for. It signs you in through the browser once, mints a key with that session, stores only the key, and signs the session back out — so afterwards nothing about the profile can open a browser, and no half-forgotten login is left behind. `--org-id` and `--project-id` narrow what the minted key can reach, exactly as they do on [`neon api-keys create`](#api-keys); a project-scoped key cannot create projects, mint keys, or read any other project.
 
@@ -934,11 +974,11 @@ Every key is verified against the API before it is stored, and the account it be
 
 `rotate-key` mints at the scope the profile already has — replacing an org key with an account key would quietly widen everything it reaches — and stores the new key before revoking the old one, so a failed write leaves the old key working.
 
-One thing it cannot do: **an organization key cannot mint its own replacement.** Neon only accepts a personal credential when creating organization keys, so rotating an org- or project-scoped profile means signing in again — `neon profile create ci --mint --org-id org-abc-123 --force`. `rotate-key` checks this before minting and says so, rather than letting the API answer with a rule you had no reason to expect.
+One thing it cannot do: **an organization key cannot mint its own replacement.** Neon only accepts a personal credential when creating organization keys, so rotating an org- or project-scoped profile means signing in again — `neon profile create ci --mint --org-id org-abc-123`. `rotate-key` checks this before minting and says so, rather than letting the API answer with a rule you had no reason to expect.
 
 Two things the CLI cannot do for a key you supplied rather than minted. It cannot revoke it, because `GET /api_keys` exposes no prefix and a stored secret cannot be matched to a listing entry, so both `rotate-key` and `profile remove` say the old key is still live and point you at `neon api-keys list`. For a key you supplied it records the organization the API reports, but cannot know whether that key was narrowed to a single project — so `rotate-key` will not suggest an organization-wide replacement without telling you to check `neon api-keys list` first.
 
-If a stored key stops working there is nothing to refresh, so recovery is one browser sign-in: `neon profile create work --mint --force`.
+If a stored key stops working there is nothing to refresh, so recovery is one browser sign-in: `neon profile create work --mint`.
 
 ### Which credential an invocation uses
 
@@ -1089,7 +1129,7 @@ Global options are supported with any Neon CLI command.
 
 - <a id="config-dir"></a>`--config-dir`
 
-  Specifies the path to the `neon` configuration directory, which holds the `credentials.json` written by `neon auth`. The default is `$XDG_CONFIG_HOME/neon`, or `~/.config/neon`; run `neon --help` to see the resolved path. This option is only necessary if you keep your configuration somewhere else.
+  Specifies the path to the `neon` configuration directory, which holds the `credentials.json` written by `neon auth` and, when a second profile exists or DEFAULT is keyring, `profiles.json`. The default is `$XDG_CONFIG_HOME/neon`, or `~/.config/neon`; run `neon --help` to see the resolved path. This option is only necessary if you keep your configuration somewhere else.
 
   The directory was called `neonctl` before the CLI was renamed. An existing one is still read, and is used **in place** — nothing is moved or copied, so there is never a second credentials file to go stale. A directory you pass explicitly is used exactly as given and never falls back to the legacy name, so pointing a CI run at a scratch directory cannot pick up local credentials.
 

package/dist/_chunks/{auth_selection-DGgq6ifc.js → auth_selection-CV_3n1du.js}

@@ -1,4 +1,4 @@
-import "./profiles-Ir29rqns.js";
+import "./profiles-CVXNvU2r.js";
 //#region ../../internals/cli-core/dist/auth_selection.js
 /**
 * # Which credential an invocation authenticates with

package/dist/_chunks/{cmd_pipeline-CUbBO9U_.js → cmd_pipeline-CEk93dGN.js}

@@ -2573,12 +2573,14 @@ const cmdEndPipeline = {
 					}
 					const isSyncOrPlaceholder = rs.fields.length === 0 && rs.command === "" && rs.rows.length === 0;
 					const isCommandOnly = rs.fields.length === 0 && rs.rows.length === 0 && rs.command !== "";
-					if (!isSyncOrPlaceholder && !isCommandOnly) if (rs.fields.length === 0 && rs.rows.length > 0) {
-						if (!ctx.settings.popt.topt.tuplesOnly) {
-							process.stdout.write("--\n");
-							process.stdout.write(`(${rs.rows.length} ${rs.rows.length === 1 ? "row" : "rows"})\n\n`);
-						}
-					} else await alignedPrinter.printQuery(rs, ctx.settings.popt, process.stdout);
+					if (!isSyncOrPlaceholder && !isCommandOnly) {
+						if (rs.fields.length === 0 && rs.rows.length > 0) {
+							if (!ctx.settings.popt.topt.tuplesOnly) {
+								process.stdout.write("--\n");
+								process.stdout.write(`(${rs.rows.length} ${rs.rows.length === 1 ? "row" : "rows"})\n\n`);
+							}
+						} else await alignedPrinter.printQuery(rs, ctx.settings.popt, process.stdout);
+					}
 				} else if (!errorRendered) {
 					const reason = r.reason;
 					const isAborted = typeof reason === "object" && reason !== null && reason.pipelineAborted === true;

package/dist/_chunks/credential_io-D2vw1UOw.js

@@ -0,0 +1,409 @@
+import { b as writeSecretFile, f as profilesFilePath, v as CRED_STORAGE_FILE, y as CRED_STORAGE_KEYRING } from "./profiles-CVXNvU2r.js";
+import { o as isOwnedCredentialPath } from "./paths-g3DRqJiD.js";
+import { tryLoadKeyring } from "../keyring.js";
+import { existsSync, readFileSync, rmSync } from "node:fs";
+import { dirname } from "node:path";
+import { createHash } from "node:crypto";
+//#region ../../internals/cli-core/dist/credentials.js
+/**
+* # Stored credentials — one file per account, two kinds
+*
+* A profile points at exactly one credentials file (see `./profiles.ts`), and that file says
+* what kind of credential it holds. Adding API-key support this way rather than adding a
+* second pointer to `profiles.json` keeps a profile what it already was — one name, one path
+* — and means `profiles.json` needs no schema change at all.
+*
+* ```json
+* // oauth: every file written before this existed. An absent `type` means this.
+* { "access_token": "…", "refresh_token": "…", "expires_at": 1786…, "user_id": "…" }
+*
+* // api_key, stored by `neon profile create --api-key`
+* { "type": "api_key", "api_key": "napi_…", "user_id": "…" }
+*
+* // api_key minted by `--mint --org-id`, which records the scope it was issued at
+* { "type": "api_key", "api_key": "napi_…", "key_id": 123, "org_id": "org-…" }
+* ```
+*
+* ## One profile, one kind
+*
+* A credentials file holds an API key or an OAuth session, never both, and `type` states
+* which. An earlier draft let the two coexist — the idea being that a key could keep the
+* session it was minted from and so rotate without a browser. It did not survive review, for
+* two reasons that are worth recording so nobody rebuilds it:
+*
+* 1. **It never worked.** The resolver returned the key without testing it, so a revoked key
+*    failed to mint and never fell back to the session sitting beside it.
+* 2. **It could mix accounts.** Nothing compared the identity of the credential being written
+*    with the one already there, so a profile could hold one account's session and another's
+*    key, told apart only by a single string. Flip or lose `type` and the profile silently
+*    becomes a different person.
+*
+* Recovery from a dead key is therefore one browser login — `neon profile create <name>
+* --mint` — which is what the retained session was supposed to save and never did.
+*
+* ## Older releases
+*
+* A CLI predating this reads the pointer, finds no `type` it understands, ignores it, and
+* looks for `access_token`. An `api_key` profile has none, so an older release falls through
+* to its browser login rather than crashing. That it does not crash is why `credentials`
+* stays a required pointer: an entry without one makes 2.41 and 2.42 throw
+* `ERR_INVALID_ARG_TYPE` from `resolveEntryPath`.
+*/
+const OAUTH = "oauth";
+const API_KEY = "api_key";
+const credentialLabel = (at) => at.storage === "keyring" ? `the OS keyring item for profile "${at.profile}"` : at.path;
+/**
+* Which credential in this file authenticates, by declaration alone.
+*
+* An unrecognised `type` throws rather than falling back to `oauth`. A file we cannot
+* interpret is a misconfiguration the user has to see: treating it as OAuth would send them
+* to a browser login that silently replaces a credential they meant to keep, and treating it
+* as an API key would authenticate with whatever `api_key` happened to be there.
+*
+* This deliberately does not check that an `api_key` file has a key — `neon profile list`
+* needs the kind of a file it is not about to authenticate with, and must be able to report a
+* broken one rather than throwing halfway through a table.
+*/
+const credentialKind = (credentials, at, store = "file") => {
+	const declared = credentials.type;
+	if (declared === void 0 || declared === "oauth") return OAUTH;
+	if (declared === "api_key") return API_KEY;
+	throw new Error(`${credentialLabel(at)} declares a "type" this version does not understand. Expected "${OAUTH}" or "${API_KEY}". ${credentialsRepairHint(at, store)}`);
+};
+const credentialsRepairHint = (at, store = "file") => store === "keyring" ? `Replace it deliberately with \`neon profile create ${at.profile}\`, or remove the profile with \`neon profile remove ${at.profile}\`.` : `Replace it deliberately with \`neon profile create ${at.profile}\`, or delete the file.`;
+/**
+* Resolve what to authenticate with, validating that the declared kind is actually usable.
+*
+* An `api_key` file with no key is a hard error rather than a fall-through to OAuth: the user
+* asked for a key, and quietly opening a browser instead would replace the credential they
+* were trying to fix.
+*/
+const interpretCredentials = (credentials, at, store = "file") => {
+	if (credentialKind(credentials, at, store) === "oauth") return { kind: OAUTH };
+	const apiKey = nonEmpty(credentials.api_key);
+	if (apiKey === void 0) throw new Error(`${credentialLabel(at)} declares "type": "${API_KEY}" but has no "api_key" value. ${credentialsRepairHint(at, store)}`);
+	return {
+		kind: API_KEY,
+		apiKey
+	};
+};
+/**
+* Read and classify a credentials file, without deciding what to do about it.
+*
+* A permission or I/O error still throws: there may be a perfectly good credential here that
+* we cannot see, and treating that as absent would send the user to a browser login that
+* overwrites it.
+*/
+/** Discard parser details because V8 may quote secret material near a syntax error. */
+const parseCredentialsJson = (contents, label) => {
+	let parsed;
+	try {
+		parsed = JSON.parse(contents);
+	} catch {
+		return {
+			kind: "unusable",
+			reason: `${label} is not valid JSON, so the credential in it cannot be read`
+		};
+	}
+	if (parsed === null || typeof parsed !== "object" || Array.isArray(parsed)) return {
+		kind: "unusable",
+		reason: `${label} does not contain a credentials object`
+	};
+	return {
+		kind: "ok",
+		credentials: parsed
+	};
+};
+const inspectCredentials = (path) => {
+	let contents;
+	try {
+		contents = readFileSync(path, "utf8");
+	} catch (err) {
+		if (err.code === "ENOENT") return { kind: "absent" };
+		throw err;
+	}
+	return parseCredentialsJson(contents, path);
+};
+/**
+* The credential at `path`, or `null` when the file is not there.
+*
+* A damaged file is an error, not an absence. Treating it as absent — which is what this used to
+* do — meant any read-only command could repair it by starting a browser sign-in and overwriting
+* it, **possibly as a different account**, with the user never having asked for a repair and no
+* way back to whatever was in the file. Failing here costs one deliberate command; the message
+* names it.
+*
+* `profile list` and telemetry use {@link inspectCredentials} instead, because describing a
+* broken credential is not the same as using one.
+*/
+const readCredentials = (at) => {
+	const read = inspectCredentials(at.path);
+	if (read.kind === "unusable") throw new Error(`${read.reason}. ${credentialsRepairHint(at)}`);
+	return read.kind === "ok" ? read.credentials : null;
+};
+const writeCredentials = (path, credentials) => {
+	writeSecretFile(path, JSON.stringify(credentials));
+};
+/**
+* Build an `api_key` credentials object. Nothing from a previous credential is carried over.
+*
+* The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint
+* the replacement on the same endpoint, and an org or project key minted as an account key
+* would silently widen what the profile reaches.
+*/
+const apiKeyCredentials = ({ apiKey, keyId, userId, scope }) => ({
+	type: API_KEY,
+	api_key: apiKey,
+	...keyId !== void 0 ? { key_id: keyId } : {},
+	...userId !== void 0 ? { user_id: userId } : {},
+	...scope?.orgId !== void 0 ? { org_id: scope.orgId } : {},
+	...scope?.projectId !== void 0 ? { project_id: scope.projectId } : {}
+});
+/** The scope recorded on a stored credential. */
+const scopeOf = (credentials) => ({
+	...typeof credentials.org_id === "string" ? { orgId: credentials.org_id } : {},
+	...typeof credentials.project_id === "string" ? { projectId: credentials.project_id } : {}
+});
+/** How to describe a scope in output. */
+const describeScope = (scope) => {
+	if (scope.projectId !== void 0) return `project ${scope.projectId}`;
+	if (scope.orgId !== void 0) return `org ${scope.orgId}`;
+	return "account";
+};
+function nonEmpty(value) {
+	if (typeof value !== "string") return void 0;
+	const trimmed = value.trim();
+	return trimmed === "" ? void 0 : trimmed;
+}
+/**
+* Whether a stored credential is the same secret as the one about to replace it.
+*
+* Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it
+* would revoke the credential the command has just committed to. Trimmed on both sides, because
+* a key read from a file or a pipe arrives with a trailing newline.
+*/
+const isSameCredential = (existingKey, replacementKey) => {
+	if (existingKey === void 0 || replacementKey === void 0) return false;
+	const trimmed = existingKey.trim();
+	return trimmed !== "" && trimmed === replacementKey.trim();
+};
+//#endregion
+//#region ../../internals/cli-core/dist/credential_store.js
+const KEYRING_SERVICE = "com.neon.neon-cli";
+/** Hashing the resolved profiles directory isolates config roots while keeping profile names visible. */
+const keyringAccount = (configDir, profile) => `cli:${createHash("sha256").update(dirname(profilesFilePath(configDir))).digest("hex")}:${profile}`;
+var KeyringUnavailableError = class extends Error {
+	constructor(profile, kind = "read") {
+		const loaded = "This CLI cannot use the OS keyring.";
+		super(profile === void 0 ? `${loaded} Drop \`--keyring\` to keep the credential in a file.` : kind === "write" ? `${loaded} Remove the profile with \`neon profile remove ${profile} --yes\`.` : `${loaded} Use --api-key or NEON_API_KEY. If this is a standalone neon binary, use the npm-installed neon instead. To reset the profile: \`neon profile remove ${profile} --yes\`.`);
+		this.name = "KeyringUnavailableError";
+	}
+};
+var KeyringUnreadableError = class extends Error {
+	constructor(profile) {
+		const replace = `\`neon auth --profile ${profile}\``;
+		super(`Could not read the OS keyring item for profile "${profile}". Unlock the keyring and retry, or run ${replace}. To reset the profile: \`neon profile remove ${profile} --yes\`.`);
+		this.name = "KeyringUnreadableError";
+	}
+};
+var KeyringClearError = class extends Error {
+	constructor(profile, kind = "visible") {
+		const recovery = `\`neon profile remove ${profile} --yes\``;
+		super(kind === "unconfirmed" ? `Could not confirm the OS keyring item for profile "${profile}" is gone. The OS store does not distinguish a missing item from denied access. Unlock the OS keyring and retry, or reset the profile with ${recovery} (a leftover may remain; it is unused once the profile is gone).` : `Could not clear the OS keyring item for profile "${profile}". Unlock the OS keyring and retry, or reset the profile with ${recovery} (a leftover may remain; it is unused once the profile is gone).`);
+		this.name = "KeyringClearError";
+	}
+};
+const deleteFileIfPresent = (path) => {
+	if (!existsSync(path)) return false;
+	rmSync(path);
+	return true;
+};
+const inspectKeyringItem = (keyring, account, label) => {
+	if (keyring === null) return { kind: "absent" };
+	let raw;
+	try {
+		raw = keyring.get(KEYRING_SERVICE, account);
+	} catch {
+		return { kind: "absent" };
+	}
+	if (raw === null) return { kind: "absent" };
+	return parseCredentialsJson(raw, label);
+};
+const createCredentialStore = (dir, options = {}) => {
+	const keyring = options.keyring ?? null;
+	const accountFor = (profile) => keyringAccount(dir, profile);
+	const assertKeyringWritable = (profile) => {
+		if (keyring === null) throw new KeyringUnavailableError(profile, "write");
+	};
+	const setKeyringOrRollback = (profile, credentials) => {
+		assertKeyringWritable(profile);
+		const kr = keyring;
+		if (kr === null) throw new KeyringUnavailableError(profile, "write");
+		const account = accountFor(profile);
+		const label = `profile "${profile}"`;
+		let previous = null;
+		try {
+			previous = kr.get(KEYRING_SERVICE, account);
+		} catch {
+			previous = null;
+		}
+		try {
+			kr.set(KEYRING_SERVICE, account, JSON.stringify(credentials));
+		} catch {
+			throw new KeyringUnavailableError();
+		}
+		try {
+			if (kr.get("com.neon.neon-cli", account) === null) throw new Error(`Wrote credentials to the OS keyring for ${label} but could not read them back.`);
+		} catch (err) {
+			if (previous !== null) {
+				try {
+					kr.set(KEYRING_SERVICE, account, previous);
+				} catch {
+					throw new KeyringClearError(profile, "visible");
+				}
+				let restored = null;
+				try {
+					restored = kr.get(KEYRING_SERVICE, account);
+				} catch {
+					restored = null;
+				}
+				if (restored === null) throw new KeyringClearError(profile, "visible");
+			}
+			throw err instanceof Error ? err : new Error(String(err));
+		}
+	};
+	const removeKeyringItem = (profile, required, account = accountFor(profile)) => {
+		if (keyring === null) {
+			if (required) throw new KeyringUnavailableError(profile, "write");
+			return "unconfirmed";
+		}
+		let raw;
+		try {
+			raw = keyring.get(KEYRING_SERVICE, account);
+		} catch (err) {
+			if (!required) return "unconfirmed";
+			throw err instanceof Error ? err : new Error(String(err));
+		}
+		if (raw === null) {
+			if (required) throw new KeyringClearError(profile, "unconfirmed");
+			return "unconfirmed";
+		}
+		let deleted;
+		try {
+			deleted = keyring.delete(KEYRING_SERVICE, account);
+		} catch (err) {
+			if (!required) return "unconfirmed";
+			throw err instanceof Error ? err : new Error(String(err));
+		}
+		let still;
+		try {
+			still = keyring.get(KEYRING_SERVICE, account);
+		} catch (err) {
+			if (!required) return "unconfirmed";
+			throw err instanceof Error ? err : new Error(String(err));
+		}
+		if (!deleted || still !== null) {
+			if (required) throw new KeyringClearError(profile, "visible");
+			return "left";
+		}
+		return "cleared";
+	};
+	const inspect = (at) => {
+		if (at.storage === "keyring") {
+			if (keyring === null) return {
+				file: "unreadable",
+				storage: CRED_STORAGE_KEYRING,
+				credentials: null,
+				reason: new KeyringUnavailableError(at.profile).message
+			};
+			const keyringRead = inspectKeyringItem(keyring, accountFor(at.profile), credentialLabel(at));
+			if (keyringRead.kind === "ok") return {
+				file: "ok",
+				storage: CRED_STORAGE_KEYRING,
+				credentials: keyringRead.credentials
+			};
+			if (keyringRead.kind === "unusable") return {
+				file: "unreadable",
+				storage: CRED_STORAGE_KEYRING,
+				credentials: null,
+				reason: keyringRead.reason
+			};
+			return {
+				file: "unreadable",
+				storage: CRED_STORAGE_KEYRING,
+				credentials: null,
+				reason: new KeyringUnreadableError(at.profile).message
+			};
+		}
+		const fileRead = inspectCredentials(at.path);
+		return {
+			file: fileRead.kind === "ok" ? "ok" : fileRead.kind === "absent" ? "missing" : "invalid",
+			storage: CRED_STORAGE_FILE,
+			credentials: fileRead.kind === "ok" ? fileRead.credentials : null,
+			...fileRead.kind === "unusable" ? { reason: fileRead.reason } : {}
+		};
+	};
+	const read = (at) => {
+		if (at.storage === "keyring") {
+			if (keyring === null) throw new KeyringUnavailableError(at.profile);
+			let raw;
+			try {
+				raw = keyring.get(KEYRING_SERVICE, accountFor(at.profile));
+			} catch {
+				throw new KeyringUnreadableError(at.profile);
+			}
+			if (raw === null) throw new KeyringUnreadableError(at.profile);
+			const parsed = parseCredentialsJson(raw, credentialLabel(at));
+			if (parsed.kind === "unusable") throw new Error(parsed.reason);
+			if (parsed.kind !== "ok") throw new KeyringUnreadableError(at.profile);
+			return {
+				credentials: parsed.credentials,
+				backend: CRED_STORAGE_KEYRING,
+				profile: at.profile
+			};
+		}
+		const credentials = readCredentials(at);
+		if (credentials === null) return null;
+		return {
+			credentials,
+			backend: CRED_STORAGE_FILE,
+			path: at.path,
+			profile: at.profile
+		};
+	};
+	const write = (at, credentials) => {
+		if (at.storage === "keyring") {
+			setKeyringOrRollback(at.profile, credentials);
+			return {
+				credentials,
+				backend: CRED_STORAGE_KEYRING,
+				profile: at.profile
+			};
+		}
+		writeCredentials(at.path, credentials);
+		return {
+			credentials,
+			backend: CRED_STORAGE_FILE,
+			path: at.path,
+			profile: at.profile
+		};
+	};
+	const del = (at, deleteOptions) => {
+		const required = deleteOptions?.required !== false;
+		if (at.storage === "keyring") return removeKeyringItem(at.profile, required, deleteOptions?.account);
+		if (!isOwnedCredentialPath(dir, at.path)) return "skipped";
+		return deleteFileIfPresent(at.path) ? "cleared" : "absent";
+	};
+	return {
+		inspect,
+		read,
+		write,
+		delete: del,
+		assertKeyringWritable
+	};
+};
+//#endregion
+//#region src/credential_io.ts
+const storeFor = (dir) => createCredentialStore(dir, { keyring: tryLoadKeyring() });
+//#endregion
+export { OAUTH as a, describeScope as c, scopeOf as d, API_KEY as i, interpretCredentials as l, KEYRING_SERVICE as n, apiKeyCredentials as o, keyringAccount as r, credentialLabel as s, storeFor as t, isSameCredential as u };

package/dist/_chunks/{paths-DMq0Lt7a.js → paths-g3DRqJiD.js}

@@ -148,4 +148,4 @@ const isOwnedCredentialPath = (configDirectory, file) => {
 	return legacy !== void 0 && isInsideConfigDir(legacy, file);
 };
 //#endregion
-export { isOwnedCredentialPath as a, isInsideConfigDir as i, credentialsPath as n, resolveConfigFile as o, defaultDir as r, CREDENTIALS_FILE as t };
+export { isInsideConfigDir as a, defaultDir as i, configDir as n, isOwnedCredentialPath as o, credentialsPath as r, resolveConfigFile as s, CREDENTIALS_FILE as t };