tool.write should enforce 0644 file mode despite umask

[SeashoreShi]

Problem

tool.write can create files with mode 0600 under strict umask environments (for example umask 077), even though tests and behavior expect 0644.

Why this matters

The project expects deterministic write permissions for files created by write paths. Under hardened environments this drift causes test failures and inconsistent behavior.

Reproduction

1. Set a strict umask (e.g. umask 077).
2. Run packages/opencode tests.
3. Observe failure in test/tool/write.test.ts (Expected 0644, Received 0600).

Expected behavior

Files written by tool.write should end up with mode 0644 regardless of process umask.

[github-actions]

This issue might be a duplicate of an existing issue. Please check:

• WriteTool fails to assign secure permissions to sensitive files #14853: Also concerns test/tool/write.test.ts and file permission modes set by WriteTool — the two issues overlap significantly on the same test file and permission behavior, though the root cause described differs (umask vs. missing explicit mode assignment).

Please review #14853 to see if your issue is already covered or if this warrants a separate fix.

[HaleTom]

PR #19077 attempts to address this by forcing 0o644 on all files via Filesystem.write(filepath, content, 0o644) + a post-write chmod to bypass umask filtering.

This is a security regression. A user running umask 077 has intentionally restricted their environment so new files are 0600 (owner-only). Forcing 0644 programmatically loosens their security boundary and makes all AI-written files world-readable — including things like .env, credentials, or private keys that the user would otherwise have protected by their umask.

The correct fix is test-side: pin process.umask(0o022) in the test so the assertion is deterministic without overriding the user's security posture in production.

With #14853 closed by its author, is there any remaining reason to override or loosen a user's umask in the write tool, rather than simply respecting it? If not, I think this issue can be closed.