Contact name displays in account menu instead of user name

[hyper-charlie]

Description

After adding a new contact, the contact's name incorrectly displays in the bottom left account menu instead of the user's own name. The user remains logged into their own account—this is a display issue only.

Steps to Reproduce

1. Add a new contact to the app
2. Check the bottom left menu
3. Observe that the newly added contact's name appears instead of the user's name

Expected Behavior

The user's own name should always display in the account menu, regardless of contacts added.

Actual Behavior

The most recently added contact's name displays in the account menu.

Environment

• Platform: macOS (aarch64)
• OS Version: macOS 26.2
• App Version: 1.0.18
• Build: e0bd093
• Locale: en-AU

Note

Issue persists after app restart.

[devin-ai-integration]

Codebase Exploration Findings

How the account menu name is displayed

The profile button in the bottom-left sidebar renders via ProfileButton → useMyName hook in apps/desktop/src/sidebar/profile/index.tsx:338-342:

function useMyName(email?: string) {
  const userId = main.UI.useValue("user_id", main.STORE_ID);
  const name = main.UI.useCell("humans", userId ?? "", "name", main.STORE_ID);
  return name || email || "Unknown";
}

This reads the user_id value from TinyBase (should always be DEFAULT_USER_ID = "00000000-0000-0000-0000-000000000000"), then looks up the name cell in the humans table for that row ID. Fallback chain: name → email → "Unknown".

How the user's own human row is initialized

In apps/desktop/src/store/tinybase/store/initialize.ts:21-35, the user's row is created with name: "" only if it doesn't already exist. This means the display should fall back to the auth email.

How contacts are created

NewPersonForm in apps/desktop/src/contacts/new-person-form.tsx (introduced in e0bd093a1 — the exact build reported by the user) creates a new humans row with crypto.randomUUID() as the row ID. This should NOT overwrite the user's row at DEFAULT_USER_ID.

For the bug to occur

Either:

1. The user_id TinyBase value is changing to point at a contact's row ID, or
2. The user's own human row (00000000-0000-0000-0000-000000000000) is getting its name cell overwritten with the contact's name

I could not find an explicit code path that causes either of these. However, since both contacts and the user share the same humans table in TinyBase's MergeableStore, and the store uses a BroadcastChannelSynchronizer across windows, there may be a CRDT merge conflict or persister race condition at play.

Relevant recent changes

Commit	Description	Relevance
e0bd093a1 (v1.0.18)	"update contact tab sidebar" — introduced NewPersonForm	User's exact build. New contact creation path was added here.
c82d24f09	Reverted "normalize current user calendar participants"	Reverted logic that deduped participant mappings; the revert removed linkedHumanIds tracking in createParticipantsFromEvent, allowing duplicate mappings.
e9779a7ee	"fix: normalize current user calendar participants"	Originally tried to deduplicate participant entries — was reverted.
23753fe1d	"fix: defer store initialization until relevant persisters complete initial load"	Made initializeStore wait for human/session/values persisters before running.

Key files

• Display: apps/desktop/src/sidebar/profile/index.tsx — useMyName hook (L338-342), ProfileButton component (L258-336)
• Contact creation: apps/desktop/src/contacts/new-person-form.tsx — NewPersonForm (L16-32)
• Store init: apps/desktop/src/store/tinybase/store/initialize.ts — initializeStore (L21-52)
• Human persistence: apps/desktop/src/store/tinybase/persister/human/ — markdown-based file persistence for humans table
• Values persistence: apps/desktop/src/store/tinybase/persister/values/persister.ts — persists the user_id value
• Schema: packages/store/src/tinybase.ts — humans table schema and user_id value schema share the same key name but are in separate TinyBase namespaces

Suggested investigation

1. Add logging to useMyName to capture the actual userId value and the name cell it resolves — this will immediately narrow it to hypothesis (1) vs (2).
2. Inspect the user's persisted data — check humans/00000000-0000-0000-0000-000000000000.md on the user's machine to see if the name was overwritten, and check the values JSON to see if user_id was changed.
3. Check for MergeableStore merge artifacts — if the control widget window is also running, the BroadcastChannel sync (hypr-sync-persisted) might be causing merge conflicts in the humans table or values store.
4. Reproduce with the NewPersonForm — since this was introduced in the exact build (e0bd093a1), the new contact creation flow is the most likely trigger.