refreshSecretNames in desktop/src/hooks/use-vault.tsx calls ensureVaultSchema before listing secrets, and that command issues a CREATE TABLE IF NOT EXISTS secrets (...) in src-tauri/src/vault_store.rs. That is a write on the read path.
For a vault shared over a drop, the recipient holds a read-only Turso token. The table already exists (you cannot share a vault that was never created), so the statement is semantically a no-op. The open question is whether libsql treats it as one: statements are classified as read or write before execution, and DDL classifies as a write, which an embedded replica forwards to the primary. If authorization keys off that classification rather than the effect, the statement is rejected and the recipient cannot open the vault at all.
To determine
Adopt a shared vault in the desktop app and open it. If the secrets list renders, there is nothing to do here and this can be closed.
Fix if it does fail
Skip ensureVaultSchema when the active vault is not owned — an adopted vault provably already has its schema. Vault.tsx already derives readOnly (cloudSync && !ownsActiveCloudVault) for the same reason.
Found while gating the vault write controls in a29047a.
refreshSecretNamesindesktop/src/hooks/use-vault.tsxcallsensureVaultSchemabefore listing secrets, and that command issues aCREATE TABLE IF NOT EXISTS secrets (...)insrc-tauri/src/vault_store.rs. That is a write on the read path.For a vault shared over a drop, the recipient holds a read-only Turso token. The table already exists (you cannot share a vault that was never created), so the statement is semantically a no-op. The open question is whether libsql treats it as one: statements are classified as read or write before execution, and DDL classifies as a write, which an embedded replica forwards to the primary. If authorization keys off that classification rather than the effect, the statement is rejected and the recipient cannot open the vault at all.
To determine
Adopt a shared vault in the desktop app and open it. If the secrets list renders, there is nothing to do here and this can be closed.
Fix if it does fail
Skip
ensureVaultSchemawhen the active vault is not owned — an adopted vault provably already has its schema.Vault.tsxalready derivesreadOnly(cloudSync && !ownsActiveCloudVault) for the same reason.Found while gating the vault write controls in a29047a.