v3.0.0 release binary ships without OAuth credentials — fatals at launch (likely root cause of #6 and #7); five further deployment findings

[floridaseating]

Hi — first, thank you for building this. Affixa's shutdown left a real gap and go-mapi is
the only credible open-source answer to it.

We have just rolled v3.0.0 out to 15 Windows workstations in a Google Workspace org, and
in doing so we hit six issues. The first one makes the published download unusable as
shipped, and I think it explains both open issues (#6, #7). Details and evidence below —
happy to open separate issues or send PRs if that is easier for you.

1. The published go-mapi-setup.exe cannot start: OAuth credentials are not baked in

On a clean Windows 11 install, the app exits immediately. %APPDATA%\go-mapi\app.log:

[ERROR] FATAL: OAuth client_id missing - build was not wired correctly
        (expected -ldflags -X main.oauthClientID, or GOMAPI_OAUTH_CLIENT_ID env var for wails dev)

Setting GOMAPI_OAUTH_CLIENT_ID alone then advances the error to client_secret missing,
so both ldflags appear to have been absent from the release build.

It looks like the v3.0.0 release workflow did not inject main.oauthClientID /
main.oauthClientSecret.

Why this probably explains the open issues:

• Failed to launch #7 "Failed to launch" — matches exactly.
• Installer creates mail client registry entry, but no install.log/runtime logs and SendTo does nothing #6 "registry entry created, but no install.log/runtime logs and SendTo does nothing" —
  the reporter saw no runtime logs because the process was dying at startup. The
  registration itself was fine.

Workaround for anyone blocked: supply your own Google OAuth client (Desktop app type)
via the environment variables the binary still honours:

setx /M GOMAPI_OAUTH_CLIENT_ID     "<your-client-id>"
setx /M GOMAPI_OAUTH_CLIENT_SECRET "<your-client-secret>"

With those set, 3.0.0 starts normally and reaches the signed-out state as intended.

Suggestion beyond the build fix: consider documenting the env-var override as a
supported enterprise option in ENTERPRISE.md. For Workspace orgs, using our own OAuth
client with Internal consent is arguably the better model anyway — the grant never
leaves the domain, and admins are not depending on a shared upstream client.

2. MAPISendDocuments is a stub that reports success

src/interceptor/mapi_impl.cpp:

ULONG MapiImpl::MAPISendDocuments(...) {
    // Stub: not implemented yet
    return SUCCESS_SUCCESS;
}

Callers using this Simple MAPI entry point get SUCCESS_SUCCESS and nothing happens — no
queue file, no draft, no error. Verified by calling it directly against the interceptor
DLL: returns 0, nothing written to %LOCALAPPDATA%\go-mapi\queue.

Explorer is not affected (sendmail.dll imports MAPISendMail/MAPISendMailW, both
implemented and working — we verified the full path end to end). But for apps that do use
it, the silent success is worse than a failure. Returning MAPI_E_NOT_SUPPORTED until it
is implemented would at least be honest.

3. Clients\Mail is a shared registry key — one DLLPath serves both architectures

The installer writes DLLPath = C:\Program Files (x86)\go-mapi\go-mapi.dll.

Worth documenting explicitly: HKLM\SOFTWARE\Clients is one of the non-redirected
registry keys, so the native and WOW6432Node views are the same key. There is only one
DLLPath, and it can only point at one architecture. 64-bit MAPI callers then fail to
load the provider with ERROR_BAD_EXE_FORMAT (193), silently.

We kept your x86 default in production (most legacy MAPI callers are 32-bit) — pointing it
at x64 just moves the breakage. Not asking for a behaviour change, but a comment in the
installer and a line in ENTERPRISE.md would save the next person the experiment.

4. Arrival toast fails to render

[ERROR] toast: arrival push failed for <id>: toast shim: load xml: LoadXml HRESULT 0xc00ce50d

0xC00CE50D is an XML parse error in the toast payload. It reproduces on every message on
Windows 11 26200. In the default manual mode the toast is the only signal that something
is waiting, so the workflow looks like it did nothing.

We work around it with "mode": "auto-draft" in settings.json (see issue 6 about that value).

5. No autostart is registered — first use after any reboot silently does nothing

The installer registers the MAPI client but nothing starts go-mapi.exe at login (no Run
key, no startup shortcut), and the interceptor DLL happily queues messages whether or not
the desktop app is running. The user-visible result after any reboot: Send to → Mail
recipient appears to do nothing at all — the envelope sits in
%LOCALAPPDATA%\go-mapi\queue with no app watching and (because of issue 4) no toast even
if one is later started.

Your own CLAUDE.md mentions the installer registering autostart as a planned Phase 10, so
this may simply not have shipped. Our fleet fix is a machine Run entry:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  go-mapi = "C:\Program Files\go-mapi\go-mapi.exe"

which works well — the app starts hidden with just the tray icon, and drains any queued
envelopes on startup. Something equivalent in the installer (ideally with a
/AUTOSTART=0 opt-out for managed fleets) would close the gap.

6. settings.json mode value is auto-draft, and unknown values silently degrade

The accepted values are "manual" | "auto-draft" (per src/app/tray.go), but that is not
documented anywhere user-facing, and an unrecognised value (we initially guessed "auto")
silently falls back to manual — which, combined with issue 4, produces the
"nothing happens" experience again. Suggestions: document the enum in ENTERPRISE.md
alongside update_checks_enabled, and log a warning (or reject) when mode is not a
recognised value instead of silently degrading.

Small note that may help other deployers

settings.json supports "update_checks_enabled": false, which pins a version without
needing a firewall rule — useful for managed fleets, and worth a mention in
ENTERPRISE.md, since blocking the binary outbound would break Gmail access entirely.

---

Environment: Windows 11 (26200) and Windows 10 22H2, x64, machine-wide install via
go-mapi-setup.exe /S, WebView2 evergreen present, Google Workspace tenant.

Thanks again for the project — happy to test any fix.