Installer creates mail client registry entry, but no install.log/runtime logs and SendTo does nothing

[JenniferEggers]

I am trying to use go-mapi on Windows to send files through Gmail from File Explorer / Microsoft Word.

I have uninstalled and reinstalled go-mapi multiple times, including running the installer as administrator. The workflow still does not work.

Symptoms:

Right-click file → Send to → Mail recipient does nothing.
The SendTo file exists and shows as Mail Service (.mapimail).
In Registry Editor, Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail has (Default) set to go-mapi.
There is a go-mapi key under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail.
I double-clicked the go-mapi .exe in C:\Program Files\go-mapi, but I see no evidence that a desktop app opens or runs.
There is no C:\Program Files\go-mapi\install.log, even though the documentation says this file should exist.
%LOCALAPPDATA%\go-mapi\logs\ does not exist.
I also tried the browser extension, but it says Disconnected — specified native messaging host not found.
There is no go-mapi entry under the browser’s NativeMessagingHosts registry location.

Question:
Should I be using the current standalone version without the browser extension? If so, how can I diagnose why the installer is not creating install.log, runtime logs, or a working SendTo/MAPI handoff?

My goal is not to use Outlook or Thunderbird. I need the Affixa-style workflow: Microsoft Word/File Explorer → Send to Mail Recipient → Gmail draft with the file attached.

Windows 11
Version 25H2

[stevenwm]

I am seeing the exact same thing. It appears to register everything correctly, but there is no Installer log. No log directory is ever generated. The desktop app will not launch. I ran the PowerShell scripts in the Diagnostics folder and they appear to show everything correctly.

When a MAPI call is triggered the app does seem to get it and I see files created in the queue folder, but nothing occurs beyond that.

[stara-home]

I hit this exact problem (Windows 11, ran installer as admin, app never launches / no UI). Root cause found, and a workaround that is now confirmed working on my machine.

Root cause: the v3.0.0 release binary was built with empty OAuth credentials. The Go build info embedded in the shipped go-mapi.exe shows the ldflags were passed with no values:

-X main.oauthClientID= -X main.oauthClientSecret=

Likely the GitHub Actions secrets GOMAPI_OAUTH_CLIENT_ID / GOMAPI_OAUTH_CLIENT_SECRET were unset when the release workflow ran — empty secrets expand silently, and installer-release.yml has no guard against it. The binary also carries the 0.0.0-dev default version string. v3.0.0-rc.1 was checked and is broken identically, so there is no working v3 asset to fall back to.

The app therefore exits before showing any UI, logging to %APPDATA%\go-mapi\app.log:

FATAL: OAuth client_id missing — build was not wired correctly

Workaround (no rebuild needed, verified working): src/app/auth_credentials.go reads GOMAPI_OAUTH_CLIENT_ID and GOMAPI_OAUTH_CLIENT_SECRET from the environment in an unconditional init() — despite the error message saying "for wails dev", it works in the release binary too. So:

1. Create your own OAuth client in Google Cloud Console: a project → enable Gmail API → OAuth consent screen (External, add yourself under Test users) → Credentials → Create credentials → OAuth client ID → Desktop app → copy the client ID and secret.

2. Set both env vars — both are required; the startup check fatals on either one being empty:

   setx GOMAPI_OAUTH_CLIENT_ID "<your-id>.apps.googleusercontent.com"
   setx GOMAPI_OAUTH_CLIENT_SECRET "GOCSPX-<your-secret>"
   

3. Relaunch go-mapi (sign out/in or reboot if it still dies — Explorer needs to pick up the new variables).

Result on my machine: startup complete (version 3.0.0) in the log, tray icon appears, Google sign-in works (expect the "unverified app" warning — click Advanced → Continue, since it's your own OAuth client), and "Send to → Mail recipient" now creates Gmail drafts as intended. Note: while your consent screen is in Testing status, Google expires the sign-in roughly weekly; re-signing in takes a few clicks.

For the maintainer: re-cutting v3.0.0 with the repo secrets populated would restore the intended zero-config experience for everyone, and a fail-fast guard in installer-release.yml when the secrets are empty would prevent a repeat. Happy to test a fixed build.

---

Note: this diagnosis and write-up were produced by AI (Anthropic's Claude, working from my machine) — it inspected the release binary's build info and the repo source, and the workaround above was executed and verified live on my Windows 11 PC before posting.