fix(security): restrict email attachments to GMAIL_ATTACHMENT_DIR

[nweisenfeld]

Attachment file paths were previously unconstrained, allowing prompt injection attacks to exfiltrate arbitrary local files (e.g. SSH keys, OAuth credentials) as email attachments.

Now requires GMAIL_ATTACHMENT_DIR to be set; attachments are disabled by default. Any path outside the configured directory is rejected via resolved-path prefix check, preventing traversal attacks.

[ArtyMcLabin]

thanks, sounds like it would overly restrict many users, but would be useful for power-users of security. how do you suggest we handle that? @nweisenfeld

[ArtyMcLabin]

@nweisenfeld Friendly ping — the design question above about opt-in vs breaking-default is still open. We like the implementation but want your input on the UX tradeoff before merging.

Due date: 2026-06-16 — If no response by then, we'll close this PR. You're welcome to reopen or submit a new PR anytime after that.

[nweisenfeld]

thanks, sounds like it would overly restrict many users, but would be useful for power-users of security. how do you suggest we handle that? @nweisenfeld

Hey @ArtyMcLabin . First off, I appreciate the work that you've done maintaining this project. I hadn't intended to forward this your way quite yet and forgot that the PR would, by default, target the upstream.

Since this would be a big, breaking change for many people using this in production, it likely would be better to have it apply no restrictions if the env var is not set and just document its presence. If there's a "best practices" writeup somewhere, it could be recommended as a way to avoid potential document leaks from anywhere.

If that makes sense to you, I'm happy to update the code and will mark this as "Ready for review" once done.