What happens
OpenWiki carefully sets POSIX permissions on its home directory everywhere it is ensured — mkdir(..., { mode: 0o700 }) + chmod(0o700) in ensureOpenWikiHome (src/openwiki-home.ts) and saveOpenWikiEnv (src/env.ts), and 0o600 on .env and the sqlite checkpoint. On Windows, however, Node's fs.chmod only toggles the read-only attribute (documented Node caveat) and the mode option on mkdir/writeFile is ignored — so none of these calls restrict anything. ~/.openwiki just inherits whatever ACL its parent directory grants.
Why it matters
~/.openwiki is the highest-value directory OpenWiki manages:
.env holds every provider API key and OAuth token in plaintext — including the ChatGPT refresh token the docs say to treat like a password,openwiki.sqlite holds full chat checkpoint state,connectors/<id>/raw/ holds raw Gmail/Slack/Notion content.
On a default %USERPROFILE% the inherited ACL is usually owner+SYSTEM+Administrators, but nothing guarantees that: any broader ACE on the profile (or a relocated home) flows straight down to the credential store. Verified on a real Windows 11 machine — a directory created under %TEMP% inherited a dozen modify-rights ACEs from its parent, and the existing chmod(0o700) left all of them in place.
Expected
On Windows, the existing 0o700 owner-only intent should be mirrored with an ACL: full control for the current user and SYSTEM only, inheritance removed — best-effort, exactly like the surrounding chmod calls (never failing a run because ACL tooling is unavailable).
I have a tightly-scoped, dependency-free fix (two icacls invocations, grant-before-inheritance-reset so a failed grant can never lock the user out) with tests ready — PR incoming.
What happens
OpenWiki carefully sets POSIX permissions on its home directory everywhere it is ensured —
mkdir(..., { mode: 0o700 })+chmod(0o700)inensureOpenWikiHome(src/openwiki-home.ts) andsaveOpenWikiEnv(src/env.ts), and0o600on.envand the sqlite checkpoint. On Windows, however, Node'sfs.chmodonly toggles the read-only attribute (documented Node caveat) and themodeoption onmkdir/writeFileis ignored — so none of these calls restrict anything.~/.openwikijust inherits whatever ACL its parent directory grants.Why it matters
~/.openwikiis the highest-value directory OpenWiki manages:.envholds every provider API key and OAuth token in plaintext — including the ChatGPT refresh token the docs say to treat like a password,openwiki.sqliteholds full chat checkpoint state,connectors/<id>/raw/holds raw Gmail/Slack/Notion content.On a default
%USERPROFILE%the inherited ACL is usually owner+SYSTEM+Administrators, but nothing guarantees that: any broader ACE on the profile (or a relocated home) flows straight down to the credential store. Verified on a real Windows 11 machine — a directory created under%TEMP%inherited a dozen modify-rights ACEs from its parent, and the existingchmod(0o700)left all of them in place.Expected
On Windows, the existing 0o700 owner-only intent should be mirrored with an ACL: full control for the current user and SYSTEM only, inheritance removed — best-effort, exactly like the surrounding chmod calls (never failing a run because ACL tooling is unavailable).
I have a tightly-scoped, dependency-free fix (two
icaclsinvocations, grant-before-inheritance-reset so a failed grant can never lock the user out) with tests ready — PR incoming.