test(WriteTool.write): File permissions respect user's umask

[HaleTom]

Issue for this PR

Fixes #19076

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

This keeps the PR surgical and limited to packages/opencode/test/tool/write.test.ts.

It updates the write-permission tests to reflect the actual contract: the write path respects the process umask instead of forcing a fixed 0644 file mode.

The permission coverage now models the real base mode and masking behavior directly:

• 0o000 confirms the unmasked base mode is 0o666
• 0o022 confirms the common masked result is 0o644
• 0o027 covers the corner case where the masked result is 0o640
• 0o077 confirms a restrictive mask produces 0o600
• 0o777 is kept as a math-only assertion so the suite documents the full masking boundary without creating an unreadable file in-process

This also avoids the competing approach in #19077, which forces 0644 after write and would loosen a user's explicit umask-based security boundary.

How did you verify your code works?

• Verified the PR diff is a single-file change with no unrelated files included.
• Confirmed packages/opencode/test/tool/write.test.ts is clean under LSP diagnostics.
• Ran bun install to bootstrap the worktree-local dependencies.
• Ran bun test test/tool/write.test.ts → 17 pass, 0 fail.
• Ran bun typecheck in packages/opencode → pass.

Screenshots / recordings

N/A — non-UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found:

• PR fix(write): enforce explicit file mode despite umask #19077 — fix(write): enforce explicit file mode despite umask
  • fix(write): enforce explicit file mode despite umask #19077
  • Why related: This PR directly addresses the production code fix for issue tool.write should enforce 0644 file mode despite umask #19076 (enforcing explicit file mode), which is the follow-up mentioned in PR test(WriteTool.write): File permissions respect user's umask #21233's description. PR test(WriteTool.write): File permissions respect user's umask #21233 fixes test determinism, while fix(write): enforce explicit file mode despite umask #19077 appears to fix the underlying issue in the actual WriteTool.execute code by passing mode: 0o644 explicitly.

These two PRs are complementary—PR #21233 stabilizes the test, and PR #19077 fixes the production code. Check if both are needed or if there's overlap in scope.

[Copilot]

Pull request overview

Makes the tool.write permission-related test deterministic across environments by controlling the process umask during the assertion.

Changes:

• Wraps the sensitive-file permission assertion in a process.umask(0o022) / restore block to avoid failures under non-default host umasks.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

Hey! Your PR title test(WriteTool.write): File permissions respect user's umask doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[HaleTom]

@rekram1-node would you please retry the failing e2e CI on this?

I wonder how many other PRs are blocked similarly?

[HaleTom]

@simonklee @thdxr — could one of you take a look at this PR? The e2e CI is failing and it would be great to get a review or a re-run.

[rekram1-node]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.