[gobby-#15001] fix: make gcode dsn refs broker-only

Author: joshwilhelmi

CHANGELOG.md

@@ -22,6 +22,26 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   daemon and CLI together. This compatibility boundary is covered by the
   Neo4j-to-FalkorDB Phase 8.3 validation matrix.
 
+## [0.8.4] — gcode
+
+### Changed
+
+#### gcode
+
+- **Broker-only PostgreSQL DSN refs** — `database_url_ref:
+  keyring:gobby:postgres_database_url` and broker-only generated refs now resolve
+  only through the local Gobby daemon broker. `gcode` no longer falls back to
+  native OS Keychain/credential-store reads from short-lived processes; broker
+  failures return a clear daemon connectivity/auth error. Inline `database_url`
+  remains supported for explicit daemonless setups.
+
+### Removed
+
+#### gcode
+
+- **Native keyring runtime path** — removed direct `keyring-core` and
+  platform-keyring-store dependencies from `gobby-code`.
+
 ## [0.8.3] — gcode
 
 ### Changed

Cargo.lock

@@ -91,11 +91,11 @@ Cargo feature flags for FalkorDB, Qdrant, or embeddings support.
 `~/.gobby/bootstrap.yaml`, requires `hub_backend: postgres`, and resolves the
 hub DSN from either `database_url_ref` or inline `database_url`. For
 `database_url_ref: keyring:gobby:postgres_database_url`, `gcode` asks the local
-daemon broker first and falls back to the native OS keyring. The DSN is not
-written to a plaintext runtime file.
-If macOS keeps asking for Keychain authorization, check `which -a gcode` and
-remove or de-prioritize stale binaries; older installs bypass daemon-brokered
-DSN resolution.
+daemon broker and fails clearly if the daemon is unavailable. It never reads
+the native OS keyring directly. The DSN is not written to a plaintext runtime
+file. For explicit daemonless setups, use inline `database_url`.
+If macOS keeps asking for Keychain authorization, check `which -a gcode`; stale
+binaries from before `0.8.4` can still read Keychain directly.
 Installing from source or crates.io requires Rust 1.88+.
 
 ### From source

README.md

@@ -1,6 +1,6 @@
 [package]
 name = "gobby-code"
-version = "0.8.3"
+version = "0.8.4"
 edition = "2024"
 rust-version = "1.88"
 authors = ["Josh Wilhelmi <hello@gobby.ai>"]
@@ -30,7 +30,6 @@ serde_yaml = "0.9"
 
 # Database
 postgres = "0.19"
-keyring-core = "1"
 
 # Graph backends
 falkordb = "0.2"
@@ -85,12 +84,3 @@ tempfile = "3"
 
 [dev-dependencies]
 serial_test = "3"
-
-[target.'cfg(target_os = "macos")'.dependencies]
-apple-native-keyring-store = { version = "1", features = ["keychain"] }
-
-[target.'cfg(target_os = "linux")'.dependencies]
-linux-keyutils-keyring-store = "1"
-
-[target.'cfg(target_os = "windows")'.dependencies]
-windows-native-keyring-store = "1"

crates/gcode/Cargo.toml

@@ -96,13 +96,12 @@ Runtime indexing/search requires a migrated Gobby PostgreSQL hub. gcode reads
 `~/.gobby/bootstrap.yaml`, requires `hub_backend: postgres`, and resolves the
 hub DSN from `database_url_ref` or `database_url`. For
 `database_url_ref: keyring:gobby:postgres_database_url`, gcode asks the local
-Gobby daemon broker for the DSN first and falls back to the native OS keyring
-when the broker is unavailable. The DSN is not written to a plaintext runtime file. The
-Gobby daemon process does not need to be running for normal index/search
-commands when keyring fallback is available.
-If macOS keeps asking for Keychain authorization, check `which -a gcode` and
-remove or de-prioritize stale binaries; older installs bypass daemon-brokered
-DSN resolution.
+Gobby daemon broker for the DSN and fails clearly when the daemon is unavailable.
+gcode never reads the native OS keyring directly. The DSN is not written to a
+plaintext runtime file. For explicit daemonless setups, use inline
+`database_url`.
+If macOS keeps asking for Keychain authorization, check `which -a gcode`; stale
+binaries from before `0.8.4` can still read Keychain directly.
 
 ### With Gobby
 
@@ -199,9 +198,8 @@ Gobby adds graph queries, graph lifecycle orchestration, semantic search, and in
 **Config and secrets are managed.** FalkorDB connection settings, Qdrant API keys, and auth credentials are stored in the shared database and encrypted with Fernet. No env vars to juggle.
 
 **PostgreSQL DSNs stay out of plaintext files.** Isolated gcode runtimes keep
-`database_url_ref: keyring:gobby:postgres_database_url`; gcode resolves it
-through the daemon broker when available and falls back to the native OS
-keyring.
+`database_url_ref: daemon:gobby:postgres_database_url`; gcode resolves it
+through the daemon broker only.
 
 **Indexing happens automatically.** The Gobby daemon watches for file changes and re-indexes in the background. Without the daemon, run `gcode index` manually.