FAQ

No. The helper binds 127.0.0.1 only and serves the UI from your machine. There is no account system, no analytics and no telemetry. Your config.json, its snapshots and any API keys stay local.

Yes, after the package is downloaded. npx needs network access the first time; the editor itself does not. The only outbound request the app makes is the schema-update check you explicitly trigger, which reads allowlisted release metadata for gsd-core and never executes remote code.

The bundled schema tracks gsd-core v1.11.0 and documents 201 keys across 24 categories: 192 carry canonical defaults and 9 are structural map keys whose sub-keys hold their own defaults. 26 keys are enumerated and carry a per-option meaning.

Use Schema maintenance → Check for updates in the editor. It checks the latest stable gsd-core release, renders the proposed changes in plain language, and lets you activate the refreshed schema or keep the current one. Unknown keys are never rejected by validation, so a newer config still loads and saves even before you refresh.

They are preserved. The canonical schema deliberately does not set additionalProperties: false, and edits are applied to the original parsed object rather than rebuilt from a key list. Unknown and future keys are surfaced in a dedicated section of the editor instead of being dropped.

The editor reports the validation problem and blocks saves until the document passes. It never writes a document that fails schema validation, and the existing file remains as it was.

Snapshots live in the OS app-data directory, under snapshots/<sha256 of the config path>. The default policy keeps the last 50 snapshots per config and skips recording when the content is identical to the most recent snapshot. History is never written inside your project or its .git.

The global defaults at ~/.gsd/defaults.json (or under GSD_HOME) are read as a provenance layer, so the editor can tell you whether a value comes from the schema default, the global defaults, or a project override. The tracked documents the tool saves are project configs.

Yes. The write pipeline adds a retry wrapper for transient Windows rename failures (EPERM, EBUSY, EACCES) that the pinned atomic-write library does not handle itself. Snapshots live under %LOCALAPPDATA%.

Pass --no-open; the server prints its loopback URL and keeps running. You still need a browser on the same machine (or a forwarded port) to use the UI. The host cannot be changed to a network interface.

Search-provider keys can live in an environment variable or in ~/.gsd/<prefix>_api_key. When the tool writes a key file it uses mode 0600, displays keys masked, and never logs them. Provider keys are also flagged sensitive in the schema and shown read-only where appropriate.

Keys marked sensitive or unsupported by the schema's editor metadata are displayed but not editable in the form UI. They can still be changed through the raw JSON editor, where validation applies as usual. The explorer marks these keys with a read-only badge.

Run npm uninstall -g open-gsd-core-config-manager (or uninstall it from your project). Your configs are untouched. Snapshots and stored key files remain until you delete the app-data directory or the key files yourself.

No. It is an independent MIT-licensed tool for editing configuration of open-gsd/gsd-core. GSD and Claude are products of their respective owners.