Repository navigation
[Bug]: ZCode store probe ignores dataBaseDir from setting.json — apply silently downgrades to the legacy unreadable file #6932
Description
Client or integration
Other — ZCode desktop (Z.ai's client) v3.14.5
Area
CLI
Summary
The ZCode client integration reports a successful apply (correct fingerprints, block present on disk), but no injected model ever appears in ZCode's model picker.
On a ZCode install whose data root has been relocated via dataBaseDir in ~/.zcode/v2/setting.json, zcodeHomeDir() resolves to ~/.zcode and never reads that setting. zcodeProviderStorePath() therefore probes a provider_config.json that does not exist, concludes the 3.14 store is absent, and falls back to writing the pre-3.14 provider.opencodex block into v2/config.json — a file ZCode >= 3.14 reads through nobody. The apply is still reported as effective.
Reproduction
-
ZCode persists its data root in
~/.zcode/v2/setting.json:{ "dataBaseDir": "D:\\Agent\\Zcode_data" } -
Confirm the store ZCode actually opens exists, and that the default-root one does not:
dir D:\Agent\Zcode_data\.zcode\v2\provider_config.json # exists (created by ZCode on first run) dir C:\Users\<user>\.zcode\v2\provider_config.json # does not exist -
Enable the ZCode client integration in the dashboard (Connection -> ZCode -> enable). The UI reports applied.
-
Read back what the integration recorded:
type %USERPROFILE%\.opencodex\integrations\records.json"zcode": { "configPath": "C:\\Users\\<user>\\.zcode\\v2\\config.json", "fragmentPaths": [ ["provider", "opencodex"] ], "fileFingerprint": "..." }
The recorded path is the legacy
v2/config.json, not theprovider_config.jsonthat exists. -
Restart ZCode, open Settings -> Model settings. The provider list contains only the built-in Zhipu entries; the injected
OpenCodexprovider is absent.
Expected: the integration writes to the provider_config.json the client actually opens, and the injected models appear after a restart.
Version
2.83.0 (latest, Windows)
Operating system
Windows 11, build 26200.9457 (DisplayVersion 2009, UBR 9457)
Provider and model
Not provider-specific. The defect is in the client-integration config export (src/clients/config-export.ts -> zcodeHomeDir / zcodeProviderStorePath); it affects any model catalog.
Logs or error output
ZCode logs no error; the apply is silent. From ZCode's own log (<dataBaseDir>/.zcode/v2/logs/<date>.log), the provider registry comes up empty on every start:
[provider-runtime][trace:Provider Registry 已就绪] {"configRevision":"[\"zcode-builtin:30:...\",\"2915b997aefbd6c7fe8ccfc87153713dc11851987034eec5a515e9660ac81b0e\"]","providerCount":0}
Two confirming observations:
- Rewriting
~/.zcode/v2/config.json(different size, different content) does not change the secondconfigRevisionelement, so the client is not reading that file. - Writing to
<dataBaseDir>/.zcode/v2/provider_config.jsondoes change that element, and the provider immediately appears in the picker.
Redacted configuration
{
"zcode": {
"clientId": "zcode",
"configPath": "C:\\Users\\<user>\\.zcode\\v2\\config.json",
"fileFingerprint": "<redacted>",
"fragmentPaths": [["provider", "opencodex"]],
"refreshablePaths": [["provider","opencodex","models","<model-id>","reasoning"], "..."],
"appliedAt": "<redacted>",
"opId": "<redacted>"
}
}The corresponding store that ZCode actually opens, shape only:
{
"schemaVersion": 1,
"config": {
"providerOrder": ["<provider-id>"],
"providerConfigRules": {
"providerRules": [
{
"providerId": "<provider-id>",
"providerName": "<name>",
"config": {
"group": "standard-personal",
"access": { "type": "api-key" },
"api": { "type": "openai-chat-completions", "baseUrl": "<loopback-url>" },
"personalModelIds": [],
"modelOrder": []
}
}
]
},
"modelConfigRules": { "providerModelRules": [], "manualProviderModelRules": [] }
}
}Notes
- This is a third variant, distinct from the two already closed: [Bug]: ZCode 3.14 integration writes to the legacy provider file and is silently ineffective — injected models never appear #5348 was "never writes provider_config.json at all", [Bug]: ZCode 3.14 integration writes provider_config.json entry without access.type — ZodError discards all personal providers (no models available) #5861 was "writes the store entry without
access.type". Here the exporter has the correct 3.14 store writer (zcode-store.ts) and the correct override plumbing, but the store probe resolves the wrong data root and silently selects the legacy fallback. zcodeHomeDir()honorsZCODE_DATA_DIRbut has no equivalent of ZCode's own persisteddataBaseDir, and ZCode's own override for the store (ZCODE_PERSONAL_PROVIDER_CONFIG_FILE) is likewise not discoverable without operator intervention.- Because the miss also pins
fileFingerprintto the legacy file, later refreshes keep rewriting the dead path instead of self-correcting.
Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
github-actions commentedon Oct 11, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
Ingwannu commentedon Oct 11, 2026
Confirmed the reported source path on current
dev9b6f4b2632492b3df637dccc009d6a01ed47c85d:zcodeHomeDir()currently considersZCODE_DATA_DIRand otherwise returns<home>/.zcode; it never reads the client's persistedv2/setting.json.zcodeProviderStorePath()builds on that result unless the explicit personal-store override is set.The downstream consequence is concrete:
resolveIntegrationTarget()probes that computed store throughIntegrationIO; when it reports missing and no current-store sentinel applies, the function permits the legacy config-file target. Thus a present relocated store is invisible to this probe, and the existing 3.14 store writer is never selected. This is a source-path confirmation, not an independent Windows/ZCode reproduction. The report is not a duplicate of either the missing-writer or missing-access-type fixes.A focused fix should reuse the existing path resolver, store writer and target-selection seam, not add another exporter. Preserve explicit
ZCODE_DATA_DIR/ZCODE_PERSONAL_PROVIDER_CONFIG_FILEprecedence; cover malformed/unreadable/relative settings without claiming an effective legacy write when the active target is unknown. Path resolution used by status, mutation planning, writer locking and restore must agree and remain injectable for synthetic tests.Please also cover an already-recorded legacy apply: changing fresh detection alone does not establish safe refresh, disable/restore or ownership migration. Retain the old path/fingerprint/recovery evidence and avoid silently abandoning an owned block while writing the relocated store. Tests should include default root, relocated root, both explicit overrides, current-store detection and existing ownership records; actual Windows picker acceptance stays a separate qualification.
Primary-source update
I checked Z.ai's published source at immutable commit
aac4755666d09fdcd70272fcf063c077a639015f(current published tree, not a separately verified 3.14.5 tag). Its data-directory specification confirms that the bootstrap remains at the default home, anddataBaseDirchanges the base above.zcode/v2. Its CLI runtime path construction joinsdataBaseDir,.zcode,v2,provider_config.json. This establishes the directory interpretation requested above without reading anyone's private configuration. The nativeZCODE_DATA_BASE_DIRselector is distinct from OpenCodex's existingZCODE_DATA_DIRconvention and should not accidentally gain the latter's suffix semantics.For a workaround using existing code, the personal-store file override can name the active absolute
provider_config.jsonfor the OpenCodex process. It does not by itself migrate an already-owned legacy block: first remove that block through the integration's normal disable operation using its original environment/path, retaining recovery snapshots, then configure the explicit store path and re-enable. Do not delete ownership records or hand-edit fingerprints to force adoption. I have not performed these operations on any live installation.No patch or Windows/native acceptance is claimed. Local execution is currently deferred because other Cargo/rustc builds are active; no overlapping tests or limit increases. Keeping this issue open for the focused regression fix. The existing detailed report is sufficient, so no private logs or credential files are requested. No live ZCode/config/ownership files were read or changed, and no native client, provider request or scan was run.
test(zcode): expect restore to re-stamp the restored ownership record (…
fix: preserve shadow-call user turns, honor ZCode dataBaseDir, forwar…
lidge-jun commentedon Oct 11, 2026
Fixed on dev by #6951 (b5f690b): the ZCode store probe honors dataBaseDir from v2/setting.json, and an unreadable bootstrap is reported instead of silently falling back to the legacy block.