fix: persist review gate config outside transient state

[fscfede-beep]

Summary

Fixes #684.

• move durable workspace config to CODEX_HOME/plugin-cc/config/<workspace>.json
• keep job state under the existing CLAUDE_PLUGIN_DATA / temp roots
• make getConfig() prefer the durable config while retaining the existing state config as a legacy fallback
• mirror setConfig() into the current legacy state for compatibility
• use the same workspace slug/hash for durable config and transient state

This removes CLAUDE_PLUGIN_DATA from the authority boundary for stopReviewGate, so Setup and Stop can run with different plugin-data environments without silently disagreeing about whether the gate is enabled.

Validation

Windows 11 / Node 26.3.1:

• test-first reproduction on main: enable under plugin-data root A, read under root B -> false (fail-open)
• after the patch the same A→B read stays true, and disabling under B is observed under A
• end-to-end integration: Setup enables the gate under root A; Stop runs under root B with the same CODEX_HOME and correctly returns a blocking review decision
• targeted Stop/setup integration: 3 passed, 0 failed
• state regression: 4 passed, 0 failed
• node --check plugins/codex/scripts/lib/state.mjs
• git diff --check

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e123511d2e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[sylvesterkaczmarek]

Moving stopReviewGate out of transient plugin state fixes the authority boundary: Setup and Stop may legitimately run with different CLAUDE_PLUGIN_DATA, but the workspace policy must remain the same. Reusing one canonical workspace key for both paths avoids a second identity scheme, and preferring durable config while mirroring legacy state gives a reasonable compatibility transition. The cross-root integration test pins the actual fail-open bug rather than only the storage helper.

[sylvesterkaczmarek]

Thanks — giving the fixtures their own CODEX_HOME is the right cleanup. It keeps the cross-root regression isolated from developer state without weakening the durable review-gate behavior being tested.

[Edo771977]

Picked this up on a fork — the durable config it introduces is the one artifact in state.mjs that is written unprotected:

function writeDurableConfig(cwd, config) {
  const configFile = resolveConfigFile(cwd);
  fs.mkdirSync(path.dirname(configFile), { recursive: true });
  const nextConfig = { ...defaultState().config, ...(config ?? {}) };
  fs.writeFileSync(configFile, `${JSON.stringify(nextConfig, null, 2)}\n`, "utf8");
  return nextConfig;
}

Everything else the module creates goes through ensurePrivateDir() (0700) and writeJsonFileAtomic() (0600, write-then-rename), and there is a test asserting exactly that for the state dir, the state file, job files and log files. The new file under CODEX_HOME lands with the ambient umask instead, usually 0644.
Two consequences:
It is world-readable on a shared machine, unlike every other file the plugin writes. Only the review-gate flag lives there today, but resolveConfigFile() is the obvious home for anything else that has to survive a CLAUDE_PLUGIN_DATA change.
fs.writeFileSync is not atomic. readDurableConfig() swallows a parse error and returns null, so a write interrupted midway (a crash, a full disk) makes the next read fall back to the state copy — silently turning the review gate off rather than failing loudly. Since the point of this PR is that the flag should survive a state-dir change, the fallback is precisely what should not be reachable.
Both helpers are already imported in that file, so the fix is a two-line swap:

 function writeDurableConfig(cwd, config) {
   const configFile = resolveConfigFile(cwd);
-  fs.mkdirSync(path.dirname(configFile), { recursive: true });
+  ensurePrivateDir(path.dirname(configFile));
   const nextConfig = { ...defaultState().config, ...(config ?? {}) };
-  fs.writeFileSync(configFile, `${JSON.stringify(nextConfig, null, 2)}\n`, "utf8");
+  writeJsonFileAtomic(configFile, nextConfig);
   return nextConfig;
 }

The PR's tests pass unchanged with it.

[sylvesterkaczmarek]

Rechecked current a81f52f9. writeDurableConfig() still writes the persistent review-gate policy directly with writeFileSync, so an interrupted write can truncate/corrupt the only durable copy, and the file mode is left to the caller umask. Since this file contains persistent trust-root/review policy, please write via a same-directory temporary file and atomic rename, enforce a restrictive mode (for example 0600), and add coverage for permissions plus preservation of the previous config when a replacement write fails.