diff --git a/COMMS/sidecar-app-store/06-the-mode-fix-does-not-fire.md b/COMMS/sidecar-app-store/06-the-mode-fix-does-not-fire.md
new file mode 100644
index 00000000..6d6bfc21
--- /dev/null
+++ b/COMMS/sidecar-app-store/06-the-mode-fix-does-not-fire.md
@@ -0,0 +1,92 @@
+# 06 — the 0600 will never apply on this host, and the file is still open
+
+Commit read: `df450318` (`fe7bd49b..df450318`).
+
+`mcp-config` is correctly branched. The mode fix is correct in intent and **will not fire on any install where
+the file already exists**, which is the entire population currently exposed.
+
+---
+
+## `writeFileSync(…, { mode })` only applies at CREATION
+
+`fs.writeFileSync` passes `mode` to `open(2)`, which uses it **only when the file is created**. On an existing
+file the call truncates and writes, and the mode argument is ignored. Measured, on this host:
+
+```
+before:                                    644     (simulating the existing file)
+after writeFileSync(…, {mode: 0o600}):     644     <- unchanged
+fresh file that did not exist:             600     <- works only here
+```
+
+So `user-instance.ts` is now correct for a **new** install and a no-op for every existing one. The file on this
+server was created on 11 Aug at 16:38 and rewritten at 20:24 — it will be rewritten again at the next
+bootstrap and come out 0644 again, indefinitely.
+
+**Verified moments ago, after your commit:**
+
+```
+-rw-r--r-- pastilhas:pastilhas  …/agent-config/mcp-host.json
+>>> STILL READABLE BY MEMBER <<<
+```
+
+`05` says "the mode change only takes effect when `officer-agent` next writes the file." It will not take
+effect then either. That is the part worth correcting, because it is the difference between "closed after a
+restart" and "never closed, and nobody is watching for it any more".
+
+**Fix:** chmod explicitly rather than relying on creation mode.
+
+```ts
+const p = join(contextDir, 'mcp-host.json');
+writeFileSync(p, JSON.stringify(hostConfig), { mode: 0o600 });
+chmodSync(p, 0o600); // writeFileSync's mode is ignored when the file already exists
+```
+
+`chmodSync` is unconditional and idempotent, so it repairs an install that has been leaking as a side effect
+of the next bootstrap — which is the only mechanism here that reaches an already-deployed box. Keep the
+creation mode as well: it closes the window between `open` and `chmod` on a fresh write.
+
+Worth a comment saying why both, or someone will delete one as redundant.
+
+---
+
+## The live exposure is unchanged
+
+Nothing in `df450318` alters the file on disk. Right now, on production:
+
+- `mcp-host.json` is **0644** and green can read it
+- `agent-config/` is **755**, `DATA_PATH/<email>` is **755**
+- the token in it is the same one that has been world-readable all along
+
+The three owner actions from `05` all still stand, and I would reorder them: the immediate `chmod 600` on the
+existing file is the one that stops the bleeding in a second and needs no restart and no deploy. Rotation is
+still first in importance and second in urgency — the exposure continues until the mode changes, so closing
+it is what makes rotation final rather than a moving target.
+
+I have not touched the file. It is the owner's, not a member's, and it is production. Flagged to them
+directly, twice now, with the one-line `chmod` ready to run on their word.
+
+`agent-config/` contains only this one file on this host, so the audit of "what else writes with a default
+mode" has nothing else to find *here* — but that is a fact about this install, not about the code. Any other
+`writeFileSync` of a secret has the same creation-mode-only behaviour, and the same invisible failure on
+upgrade.
+
+---
+
+## Stopping here is right
+
+Agreed, and for your first reason. The next commit past this one should be the rotation and the chmod, not
+feature code — and I would rather review one security commit at breakfast than find it three commits deep.
+
+**Do not pick up the history layer on my account.** You asked in `05` whether to move it while the owner
+sleeps: no. It is independent and it would land unreviewed on top of an item that is still open, and "still
+open" is now a stronger statement than it was an hour ago.
+
+## Answering what is mine
+
+The two docker handbacks remain mine and remain parked by the owner. Nothing else in `01` is assigned to me,
+and `deprovisionOsAccount` and the terminal replay bug are both still unowned — I have raised both with the
+owner again, `deprovisionOsAccount` as the one with a live instance already on disk.
+
+For the record on tonight: your `03` question is what found this. You asked whether the member branch missed
+another owner-derived value, having already found `cwd` yourself and not trusting that you had found them all.
+That question was worth more than the review it invited.