[Bug][fs-local] Files created by the write tool are always 0600 on POSIX, ignoring umask and defeating default ACLs

[avpanasyuk]

Package: @deepseek-ai/dsh-fs-local. Read in 0.1.5-rc.3, 0.2.0-rc.2 and 0.2.1-alpha.2; the code is unchanged across them. Platform: Linux/POSIX.

What happens

A file created by the model's write tool (ctx.fs.writeText → writeFileAtomic) always ends up mode 0600, whatever the process umask and whatever the directory's default ACL say. lib/index.js (0.2.0-rc.2, ~531-546):

await mkdir(stagingDir, { mode: 448 });          // 0700
await chmod(stagingDir, 448);
handle = await open(tempPath, "wx", 384);        // 0600
await handle.chmod(384);                         // explicit fchmod 0600
...
if (mode !== void 0) await handle.chmod(mode);   // only when the target already existed

writeText passes existing?.mode, so for a new file mode is undefined and the 0600 staging mode is what gets published.

Why it is a problem

• Shared directories break. A group-writable project directory (setgid dir, umask 002) ends up with files the rest of the group cannot read. An editor, git checkout or cp would have produced 0664 there.
• POSIX default ACLs are defeated outright. With a default ACL on the directory, the creating mode's group bits become the new file's ACL mask. The explicit fchmod 0600 makes the mask ---, so every named-user/named-group entry the default ACL granted is masked off. We see this on a Linux host where several service uids share a workspace through default ACLs: every .md the agent creates turns up 0600 / mask::--- and needs an external repair.
• The README does not describe this. It says "Writes preserve file permissions" and "an existing file's mode is preserved and Windows DACLs survive replacement", but nothing about the mode of a new file. On an edit, the replacement inode keeps the mode bits but not the old file's own POSIX ACL entries, unlike the Windows DACL path.

The 0600 is clearly right for the temp file while it sits in the private staging dir. The problem is that it leaks into the published file.

Suggested fix

For a new file, fchmod the temp to 0o666 & ~process.umask() before publishing, the same way mode is applied for an existing file. A config key such as newFileMode would also do. Either way, the result matches what every other writer on the system produces, and default ACLs keep working, because the mask then comes from the group bits the umask allows. Optionally, for edits on Linux, copy the old file's system.posix_acl_access xattr, mirroring what is already done for Windows DACLs.

[argszero]

Confirmed — the fix point is the mode === undefined branch of writeFileAtomic

Verified against source on master @ 5badb1500. Everything in the report holds, and the code narrows it to a single branch.

writeText hands the existing destination's mode straight through (packages/fs/fs-local/src/index.ts:239):

await writeFileAtomic(target.targetKey, content, existing?.mode, signal, this.internals, …)

and writeFileAtomic's own contract states the gap in as many words (packages/fs/fs-local/src/fsio.ts, doc comment at :575):

@param mode — existing destination's POSIX mode to preserve, or undefined for a new file

So on the create path the only mode ever applied is the staging protection:

await mkdir(stagingDir, { mode: 0o700 }); await chmod(stagingDir, 0o700)   // :616-618
handle = await open(tempPath, 'wx', 0o600)                                 // :620
await handle.chmod(0o600)                                                  // :621
…
if (mode !== undefined) await handle.chmod(mode)                           // :623 — never for a new file

and the 0600 inode is then published by rename (:646/:649) — or, under createIfAbsent, by the hard-link branch (:635), which carries the temp's mode identically. The 0o600 is right where it is: :575 states the staging directory and file are deliberately 0o700/0o600 while private. The defect is that publication never re-decides between "this inode is staging-private" and "this is the file's own mode".

Three things a fix has to cover, all in that one file:

1. New-file mode. Apply 0o666 & ~process.umask() in the mode === undefined branch before publication. That is the one point both publication paths share, and it is also where the ACL mask is decided: the staged 0o600 pins it to ---, which is exactly why the default-ACL entries end up present but inert, as you observed.
2. Keep the change in fs-local, not in the shared helper. mode is required by @deepseek-ai/dsh-atomic-write (packages/util/atomic-write/src/index.ts:54, applied at :88 as writeFile(temp, content, { mode: options.mode, flag: 'wx' })), and its other callers pass 0o600 deliberately for user-private trees (boot/config-editor, boot/plugin-manager, credentials/credentials-local, boot/app-boot/profile-compatibility). Changing the helper's default would widen those instead.
3. The POSIX/Windows asymmetry you name. On the replacement path the fresh inode keeps the mode bits but never the target's own system.posix_acl_access, while the Windows path copies the DACL on purpose (copyFileDacl at :623). Copying the ACL xattr on POSIX would mirror that existing Windows branch — and it only starts to matter once (1) stops forcing the mask to ---.

README. The gap is real: packages/fs/fs-local/README.md:12 says "Writes preserve file permissions" and :74 says "an existing file's mode is preserved and Windows DACLs survive replacement". Both statements are about the existing-file case; the mode of a newly created file is documented nowhere, and that is precisely the case every write tool call takes on a fresh path.

On the plugin question (this is the kind of gap we look at for plugin-shaped carriers): a plugin can only mitigate. ctx.fs is a shadowable Cordis service, and writeText's FsWriteOutcome already reports operation: 'create' | 'update', so a wrapper could re-chmod the target after the provider returns without re-probing. But that leaves a window in which the published file is 0600, it cannot set the creation-time mode that decides the ACL mask, and it misses every non-tool writer. This one belongs upstream in fsio.ts; a plugin is not the right carrier for it.