macOS: file-access permission not persisted on save (release is ad-hoc signed / not notarized)

[PathGao]

Describe the bug

On macOS, Markpad repeatedly asks for file-access permission every time it saves a file into a protected folder (Desktop / Documents / Downloads), even after the user has explicitly allowed access in System Settings and even after granting Full Disk Access to the app. The grant never "sticks" — the prompt returns on the next save.

Opening files does not trigger the prompt (the macOS Open panel / Powerbox implicitly grants access to the user-selected file). The problem is specific to the write/save path.

Likely root cause

The distributed macOS app is ad-hoc signed and not notarized, so macOS cannot pin a TCC / Full Disk Access grant to a stable code-signing identity, and re-prompts on each protected-folder write. Evidence from the installed app (/Applications/Markpad.app):

$ spctl -a -vvv /Applications/Markpad.app
/Applications/Markpad.app: rejected
source=no usable signature

$ codesign -dvv /Applications/Markpad.app
Identifier=Markpad-60fe2234e2ef4c98
Signature=adhoc
TeamIdentifier=not set

# no sandbox / files entitlements
$ codesign -d --entitlements :- /Applications/Markpad.app   # (empty)

Because the signature is ad-hoc (no Developer ID, unstable auto-generated identifier), TCC treats the grant as untrusted / non-persistent. Granting Full Disk Access does not resolve it.

This was verified on the official v2.6.11 release (downloaded via browser, not a local build) — the app still carries its download quarantine attribute:

$ xattr -l /Applications/Markpad.app
com.apple.quarantine: 03c1;........;Chrome;........
# CFBundleShortVersionString = 2.6.11, binary dated Jun 2026

To Reproduce

1. On macOS, open a Markdown file located on the Desktop (or in Documents/Downloads).
2. Edit it and save (⌘S) back to the same location.
3. macOS shows a "Markpad wants to access files in your Desktop folder" prompt. Click Allow.
4. Grant Markpad Full Disk Access in System Settings → Privacy & Security.
5. Edit and save again — the permission prompt still appears. The grant is not remembered.

Expected behavior

After allowing access once (or after granting Full Disk Access), saving to Desktop / Documents / Downloads should not prompt again. The grant should persist across saves and app launches.

Suggested fix

Sign the macOS release with a Developer ID Application certificate and notarize it (staple the ticket). TCC / Full Disk Access grants are keyed to a stable code-signing identity; a Developer-ID signature gives macOS a stable identity to persist the grant against. An ad-hoc signature does not.

This was confirmed on the official downloaded v2.6.11 release (not a local build), which spctl reports as having no usable signature.

Device

• OS: macOS (Darwin 25.5.0)
• App Version: v2.6.11 (official release, downloaded)

Additional context

The app is not sandboxed, so file access to Desktop/Documents/Downloads is governed by TCC folder permissions rather than security-scoped bookmarks. Saving is a direct filesystem write to the target path, which is what triggers the TCC check on every write when the signing identity is not trusted/persistent.

[PathGao]

Confirmed again on the official v2.6.14 bundle: Signature=adhoc, TeamIdentifier=not set, and spctl reports source=no usable signature. The repeated folder-access prompts are therefore not fixable by Full Disk Access alone; macOS cannot bind a persistent TCC grant to this release identity.

PR #294 adds Developer ID signing + notarization support to the release workflow and documents the required repository secrets. Once those secrets are configured and the PR is merged, the next signed/notarized release can resolve the root cause.

[PathGao]

Reframing this as a release prerequisite rather than a code PR: the current v2.6.14 bundle is ad-hoc signed, so macOS cannot retain its TCC folder grant. Full Disk Access cannot correct that identity problem.

To resolve it for a future release, a repository owner needs to:

1. Enroll the releasing organization in the Apple Developer Program.
2. Create a Developer ID Application certificate, export it as a password-protected .p12, and store its base64 value plus its password as GitHub Actions secrets.
3. Add notarization credentials: either an App Store Connect API key or an Apple ID app-specific password with the team ID.
4. Build, notarize, staple, and verify the DMG/app with spctl -a -vvv before publishing.

Tauri’s official guide covers the required certificate and notarization variables: https://v2.tauri.app/distribute/sign/macos/

Until that is available, the practical workaround is to disable Auto-save (or enable Confirm before save) for documents in Desktop, Documents, or Downloads. Each automatic write can otherwise trigger another system prompt.

The CI proposal in #294 was closed because the required credentials are not currently available; a strict workflow gate would block all releases without solving that prerequisite.

[alecdotdev]

@PathGao I believe a Apple Dev Program fee runs about $100/yr. I'll check our macos userbase and look into applying tomorrow. thanks for bringing this to my attention, as a windows dev I've yet to test on a mac

[PathGao]

@alecdotdev Don't worry — there's no need to take on the Apple Developer Program cost purely for cross-platform development.

I used to be an Apple Developer, but I have not renewed my membership recently. I may renew it later; if signing and notarization are still needed then, we can revisit whether my Apple Developer ID can be used for the release process.