Stuck on "Connecting..." indefinitely after restoring wallet from seed phrase with recent birthday

[DanielAbigail]

Please make sure you have the latest Zingo PC.
Version: 2.0.17 (macOS, non-MAS DMG build)

---

Describe the bug

After restoring a wallet from a seed phrase with a very recent birthday (within a few hours of the current chain tip), the app gets permanently stuck displaying "Connecting..." in the sidebar. The lightwalletd server (https://zec.rocks:443) is reachable and returns the latest block height successfully — but the sync process never actually starts, so the wallet never transitions to "Syncing" or "Connected". The wallet file (zingo-wallet-5.dat) is created on disk and is several hundred KB, confirming the restore itself completed. The issue appears to be that run_sync() either silently fails or the sync task is never launched after wallet initialization, causing poll_sync() to perpetually return "Sync task has not been launched." with verificationProgress remaining null.

To Reproduce

Steps to reproduce the behavior:

1. Open Zingo PC on macOS (version 2.0.17, DMG build)
2. Go to Wallet → Add New Wallet
3. Select "Restore from Seed Phrase"
4. Enter a valid 24-word seed phrase
5. Enter a birthday that is within the last few hours of the current block height (e.g., ~2890000 for mainnet as of June 2026)
6. Select the default server (https://zec.rocks:443, mainnet)
7. Click "Restore Wallet"
8. Observe: after the loading screen completes and the dashboard appears, the sidebar status indicator shows only the yellow "Connecting..." state and never progresses to "Syncing" with a percentage

Expected behavior

After restoring a wallet with a very recent birthday, the sync should complete almost instantly (since there are few or no blocks to scan). The sidebar should briefly show "Syncing" at 100%, then transition to a green "Connected" state. Alternatively, if sync fails, a visible error should be shown.

Desktop (please complete the following information):

• OS: macOS 12.7.6

(Apple Silicon / arm64)

• App Version: 2.0.17 (DMG, non-MAS)
• Server: https://zec.rocks:443 (mainnet, default)

Additional context

• info_server() succeeds — the latest block height is returned correctly, confirming network/server connectivity.
• The wallet file exists at ~/Library/Application Support/Zcash/zingo-wallet-5.dat (~hundreds of KB).
• poll_sync() keeps returning "Sync task has not been launched.", triggering refreshSync() → run_sync() repeatedly, but the sync task never seems to actually launch.
• verificationProgress stays null, which is the direct cause of the "Connecting..." display (see Sidebar.tsx lines 185–199).
• No useful console logs are available from the production DMG build because console-message events are not forwarded to startup.log when running with sandbox: true.
• The same seed/birthday/server combination likely works fine on other Zingo/zcashd setups — the issue appears specific to the gRPC streaming sync initialization path in v2.0.17 on macOS.
• Suspect root cause: the gRPC streaming connection (used by sync()) fails silently while the one-shot gRPC call (used by get_latest_block() / info_server()) succeeds. This could be related to TLS certificate handling, HTTP/2 negotiation, or the tokio runtime on macOS arm64.

---

[DanielAbigail]

i also tried MAS version and it always crashed.

[juanky201271]

Thanks for reporting, we are now working on a zingolib patch for NU 6.2 a critical security update, and after that we need to publish a new release of ours Apps, Zingo iOS, Zingo Android & Zingo PC, the ETA for this will be a few hours...

NOTE: Whe you install the next release can you, please, share with us more details about the MAS crashing? Thanks in advance.

[DanielAbigail]

thank you, this project is so great!

[DanielAbigail]

i also tried MAS version and it always crashed.

btw i tested MAS version again, and it crashed on:

[46216:0605/121156.033663:ERROR:chrome/browser/process_singleton_posix.cc:1185] Failed to bind() /var/folders/nq/4x4s4ypd6zd44gjmtykfyfn80000gn/T/co.zingo.pc/S/SingletonSocket: Operation not permitted (1)```

[juanky201271]

Hi @DanielAbigail, thanks for the extra detail!

About the MAS crash: Looking at the command you ran:

/Applications/Zingo\ PC.app/Contents/MacOS/Zingo\ PC ; exit;

The process_singleton_posix.cc bind error with EPERM is most likely caused by launching the binary directly from Terminal, which bypasses macOS LaunchServices. For a sandboxed (MAS) app, this leaves the process in an inconsistent state: the sandbox is enforced (so bind() on a Unix socket outside the container is denied), but os.tmpdir() still resolves to the regular user temp directory (/var/folders//T/...) instead of the sandbox container's temp dir. Chromium then tries to bind the singleton socket at a path the sandbox refuses → Operation not permitted.

Could you try launching it the way macOS expects, and let us know if it still crashes?

open -a "Zingo PC"

or simply double-click it in Finder / launch it from Launchpad

If it still crashes when launched via open or Finder, that would be a real bug and we will dig deeper. But based on the error, the direct-binary launch is the most likely cause.

Thanks again for the careful reporting!

[DanielAbigail]

Hi @DanielAbigail, thanks for the extra detail!

About the MAS crash: Looking at the command you ran:

/Applications/Zingo\ PC.app/Contents/MacOS/Zingo\ PC ; exit;

The process_singleton_posix.cc bind error with EPERM is most likely caused by launching the binary directly from Terminal, which bypasses macOS LaunchServices. For a sandboxed (MAS) app, this leaves the process in an inconsistent state: the sandbox is enforced (so bind() on a Unix socket outside the container is denied), but os.tmpdir() still resolves to the regular user temp directory (/var/folders//T/...) instead of the sandbox container's temp dir. Chromium then tries to bind the singleton socket at a path the sandbox refuses → Operation not permitted.

Could you try launching it the way macOS expects, and let us know if it still crashes?

open -a "Zingo PC"

or simply double-click it in Finder / launch it from Launchpad

If it still crashes when launched via open or Finder, that would be a real bug and we will dig deeper. But based on the error, the direct-binary launch is the most likely cause.

Thanks again for the careful reporting!

Yes, I initially launched the app from launchdPad/finder, but it quit immediately without any errors or crash logs, so I tried launching it from the terminal and got that error.

[juanky201271]

This is weird... we are waiting for the Apple Store approval of a new release, I hope the new one work for you... Thanks @DanielAbigail for reporting.