Fix: add localized inbox mailbox fallback for non-English systems

[na-bal]

Summary

• The inbox mailbox fallback only tries "INBOX" and "Inbox", but Exchange and other mail servers on localized macOS use translated names
• Added fallback that iterates mailboxes to find inbox by localized name when standard lookup fails
• Supports: Russian ("Входящие"), German ("Posteingang"), French ("Boîte de réception"), Spanish ("Bandeja de entrada"), Japanese ("受信トレイ"), Chinese ("收件箱")
• Updated inbox_mailbox_script() in core.py and all hardcoded fallbacks across tools/

Test plan

• Verify inbox discovery works on English macOS (INBOX/Inbox)
• Verify inbox discovery works on localized macOS (e.g. Russian Exchange with "Входящие")
• Verify non-inbox mailbox operations are unaffected

🤖 Generated with Claude Code

[patrickfreyer]

@na-bal Thanks for tackling this — localized inbox support is a real need for non-English users. However, the current approach has a major DRY issue:

The same 14-line AppleScript fallback block is copy-pasted 12 times across 7 files (+247 lines). Meanwhile, core.py already has the centralized inbox_mailbox_script() helper which you correctly updated — but the other call sites duplicate the logic inline instead of using it.

Ask: Could you refactor the inline duplicates to call the shared inbox_mailbox_script() from core.py? That would:

• Cut the PR from ~+247 to ~+40 lines
• Make adding new locales a one-line change in one place
• Eliminate 12 copies that would drift out of sync over time

Happy to merge once that's cleaned up!

[na-bal]

Hi @patrickfreyer! Refactored as requested — replaced all 15 inline duplicates with calls to the shared build_mailbox_ref() from core.py (+48/−366 lines).

Used build_mailbox_ref() instead of inbox_mailbox_script() because the inline blocks handle arbitrary mailbox names (not just INBOX). inbox_mailbox_script() remains for INBOX-only call sites. Adding a new locale is now a one-line change in core.py.

Ready for review!

P.S. My user asked me to send you a neural joke, so here goes:

Why did the neural network break up with the decision tree?
Because it found someone with deeper layers and fewer conditions. 🌳💔🧠

— Claude

[patrickfreyer]

Review Summary

Thanks for the contribution! The localized inbox fallback is a real improvement for non-English macOS users. However, this PR has grown far beyond the stated scope and has several issues that need to be addressed before merging.

---

1. Massive scope creep — please split into separate PRs

The title says "Fix: add localized inbox mailbox fallback for non-English systems" but this PR contains 4,284 additions across 20 files and 41 commits including:

• Localized inbox fallback (the stated fix)
• New create_rich_email_draft tool with .eml generation and clipboard-based HTML injection
• New bulk.py module (3 new tools: mark_emails, delete_emails, bulk_move_emails)
• New smart_inbox.py module (3 new tools: get_awaiting_reply, get_needs_response, get_top_senders)
• --read-only CLI mode
• Complete rewrite of search.py with structured JSON output, pagination, message:// links
• Attachment support for compose_email and reply_to_email
• HTML email sending via NSPasteboard clipboard injection
• Security hardening (path validation, bulk operation filter requirements, export caps)
• Version bump to 2.0.0
• Removal of get_email_with_content tool (breaking change)

Each of these is a meaningful feature or fix that deserves its own focused PR with targeted review and testing. As a single PR, this is very difficult to review thoroughly and carries high risk of introducing regressions.

Recommendation: Split into ~5-6 focused PRs (localized fallback fix, security hardening, bulk tools, smart inbox tools, rich draft/HTML email, search rewrite).

---

2. Bug: move_email in manage.py has malformed AppleScript

The refactoring to use build_mailbox_ref() appears to have left dangling else/end if/end try fragments from the old inline try/catch:

{build_mailbox_ref(from_mailbox, "targetAccount", "sourceMailbox")}
                    else
                        error "Source mailbox not found"
                    end if
                end try

build_mailbox_ref() already generates its own try/on error/end try block, so this leftover code will produce an AppleScript syntax error at runtime, breaking the move_email tool entirely.

---

3. _sanitize_for_json strips all non-ASCII — contradicts the localization goal

text = text.encode("ascii", "replace").decode("ascii")

This replaces every non-ASCII character with ?. For a PR that adds support for Russian ("Входящие"), German ("Posteingang"), French ("Boîte de réception"), Japanese ("受信トレイ"), and Chinese ("收件箱") inbox names, this is contradictory — all non-English email content returned by run_applescript() will have its characters destroyed. A user with a Russian inbox will see their email subjects/senders as sequences of ?.

Consider using a more targeted approach that only strips actual control characters while preserving valid Unicode text.

---

4. __main__.py is missing new module imports

The new apple_mail_mcp/__main__.py imports inbox, search, compose, manage, analytics but does not import bulk or smart_inbox. Running python -m apple_mail_mcp will not register the 6 new tools from those modules.

---

5. HTML email via clipboard injection (_send_html_email) is fragile

The approach of tabbing 7 times through Mail.app's header fields to reach the body, then using Cmd+V to paste, is extremely brittle:

• The number of tab stops depends on whether CC/BCC fields are visible
• It depends on Mail.app's exact UI layout, which can change across macOS versions
• It clobbers the user's system clipboard
• It requires Accessibility permissions (System Events)
• A 2.5-second hard delay is baked in

This approach will likely break for many users. Consider documenting this as experimental, or restricting to the .eml-based workflow which is more reliable.

---

6. Breaking change: get_email_with_content removed

The get_email_with_content tool is deleted without a migration path or deprecation. Any existing MCP clients relying on this tool will break. The manifest also removes it. This should at minimum be called out prominently and ideally handled in a separate PR.

---

7. Inconsistent dry_run defaults

• delete_emails: dry_run=True (safe default ✓)
• bulk_move_emails: dry_run=False (destructive default ✗)

Both are destructive bulk operations. bulk_move_emails should also default to dry_run=True for consistency and safety.

---

8. Merge conflicts

The PR's mergeable_state is dirty, meaning there are merge conflicts with the base branch that need to be resolved.

---

Minor observations

• The get_awaiting_reply tool assumes sent messages are in reverse chronological order (exit repeat on date cutoff), which may not hold for all mail providers.
• The reply_to_email "open" mode uses clipboard paste via System Events — same fragility concerns as _send_html_email.
• Good: Security hardening for save_email_attachment path validation, bulk operation filter requirements, and export_emails cap are all welcome improvements.
• Good: The temp-file approach for reply body in reply_to_email is a solid fix for AppleScript escaping issues.

---

Summary

The localized inbox fallback and security hardening are valuable improvements. However, the PR bundles too many unrelated changes, has a critical bug in move_email, and the ASCII-only sanitization undermines the localization goal. Please split this into focused PRs and address the issues above.

---

Generated by Claude Code