beta.99: TaskNotes approval loops with update-required error despite healthy latest connector and valid v0.3 collection

[pplebel]

Problem

TaskNotes connection setup loops back to approval/error on macOS with the latest published mdbase Connect release, 0.1.0-beta.99. The portal offers a valid local test collection, allows permission review, then rejects Set up and allow access with:

Update mdbase connect on this computer before approving this application.

TaskNotes subsequently displays:

The operation exceeded its request deadline.

The user is returned to Choose a collection. A fresh request reproduced the same portal error; this is not limited to an expired approval page.

Environment and checks

• macOS / Apple Silicon, official desktop beta.99.
• Bundled CLI: mdbase 0.1.0-beta.99, engine 0.4.0-rc.4, local control protocol 5.
• Managed service runtime also reports beta.99. connect doctor reports healthy; connect status reports connected, direct access available, not paused.
• One daemon process observed. A later reproduction used a different daemon PID from the initial session.
• App: https://app.tasknotes.dev/ ; portal: https://connect.mdbase.dev/ . Reproduced in Brave on the Mac; the user also encounters the approval/error loop when configuring TaskNotes on iOS.
• Beta.99 was the newest published release when checked on 2026-09-14.

Collection preparation

Testing uses an isolated copy, not the working vault. The copy was migrated to mdbase 0.3 and given a candidate type implementing the unchanged tasknotes.task 0.3.0-rc.3 contract from the official TaskNotes pack. The binding preserves custom field mappings and filename title storage. Legacy data was repaired only on the disposable copy. Full native validation returns valid: true with zero diagnostics. Native CLI synthetic create/edit/read tests passed.

This is a customized collection, not a claim of reproduction with an untouched default seed. However, the portal offers it as compatible and reaches setup review rather than displaying the previous mdbase 0.2 upgrade warning.

Reproduction observed

1. Open TaskNotes and choose a collection.
2. Sign into the existing mdbase account in the authorization popup.
3. Select the registered local mdbase 0.3 compatibility-test copy.
4. Review the requested whole-collection capabilities (read/create/edit/delete records, views, definitions, background scheduling, and file actions).
5. Review setup: TaskNotes task pack 0.3.0-rc.12, Scratchpad packs 1.1.0, and the Bases include configuration.
6. Click Set up and allow access.
7. Portal displays the update message despite the running beta.99 connector; TaskNotes eventually times out and offers collection selection again.

Expected: complete setup/authorization and return a usable connection, or report the specific incompatible protocol/capability and actionable supported version. Repeated approval should not be the only apparent recovery.

Grant state and correlation evidence

An early failed attempt had no grant for the test collection. After the user's subsequent configuration attempts, native connect access list showed one TaskNotes grant for that test collection, created 2026-09-14T14:43:02.142Z. We cannot attribute that grant to a particular attempt or prove its callback completed. The presence of the grant did not establish a usable app connection.

The CLI grant summary reports:

{"authorization_binding":5,"durable_mutation":1,"operation_transport":3,"semantic_capabilities":1}

This is only the CLI summary, not a capture of the signed wire binding; its serialization may matter.

Expired/diagnostic request IDs for server-side correlation on 2026-09-14:

• 63e23338-0380-4488-b087-671fe4c2fd11: initial observed failed approval.
• a083b82c-47f0-4c00-b53a-d354e7041574: fresh request that reproduced the same final-approval error after the grant above existed.

Investigation limits

The reviewed beta.99 approval-service.ts emits this exact message when relay.supportsContracts(...) fails, before activation. That suggests checking the selected relay session and requested contract requirements, but the deployed root cause is not established. Please correlate the request with the relay session's advertised support, routing/readiness, and actual requirements. No security or compatibility checks were bypassed.

A native daemon restart attempt separately failed with a missing dev.mdbase.connect service; start then reported already running and status remained connected. A later process check showed a new PID, so we are not claiming a verified restart fixed or caused the failure.

Related context: #353 covers relay compatibility gates but describes a different release/scenario. This is separate from #426 (Electron/Sigstore updater verification). No task contents, vault filenames, credentials, or tokens are attached.

[callumalpass]

Thanks for the detailed report and isolation work.

We’ve reproduced a potentially related approval failure with a beta.99 connector: large test collections hit a setup deadline after roughly 30 seconds, while smaller collections pass. However, the error we observed differs from your “Update mdbase connect” message, so we haven’t confirmed the same cause.

Could you clarify:

• Approximately how many Markdown files are in your test collection, and its total size?
• Does the update-required message appear immediately after clicking Set up and allow access, or after a noticeable wait? An approximate duration would help.

The request IDs you’ve already supplied are helpful for server-side correlation. No need to share your collection contents or repeat the migration.

[pplebel]

Thanks—here are the measurements from the same isolated test copy:

• Approximately 5,814 Markdown files (including type/contract definitions and excluded templates).
• 6,614 content files total, occupying 560,682,087 bytes: about 561 MB / 535 MiB, including attachments and excluding runtime/cache directories (.mdbase, .obsidian, .git, .trash).

The “Update mdbase connect on this computer before approving this application” message appeared almost immediately on the fresh retry—roughly one second after clicking Set up and allow access. The recorded click-plus-UI-state-check call completed in 0.875 seconds with the error already visible. This is an approximate UI observation, not a precise network timing measurement, but it did not look like a 30-second wait.

The TaskNotes “The operation exceeded its request deadline” message appeared later, on the originating app page. We did not precisely time that later timeout, so these should be treated as two separately observed stages rather than one measured delay.

No migration was repeated to obtain these measurements.

[callumalpass]

Thanks for those details @pplebel .

I believe that the issues you're seeing were caused by the large collection.

I've deployed some changes in mdbase connect release 102. Would you please try connecting to the collection again?

I have noticed that the “Update mdbase connect on this computer before approving this application” error appears when approving a collection very quickly. Usually, waiting a couple of seconds after the error appears, and trying again seems to cause it to disappear. I will continue investigating what is causing that behaviour.