[Bug]: macOS DMG GUI and npm backend cannot discover each other; GUI stays at “Waiting for Gateway health” even when gateway is healthy

[ManPetrauskas]

Tura version or commit

0.1.34

Affected surface

GUI or Tauri

Relevant environment

macOS 26.5.2 (25F84), Apple Silicon arm64, Tura GUI 0.1.34 installed from the macOS DMG, tura-ai 0.1.34 installed globally through npm

Minimal reproduction

1. Install the backend/CLI:

   npm install -g tura-ai@0.1.34

2. Confirm that the tura CLI works.

3. Install the macOS arm64 GUI from the release DMG into /Applications.

4. Launch tura_gui from Finder.

5. Observe that it remains indefinitely at:

   Waiting for Gateway health...

6. Manually start the gateway:

   tura_gateway

7. Confirm that it starts successfully on http://127.0.0.1:4126 and that:

   GET http://127.0.0.1:4126/global/health

   returns a healthy response.

8. Observe that the GUI still remains at “Waiting for Gateway health...”.

9. Attempt to open the GUI from the gateway tray. The gateway repeatedly reports:

   failed to open Tura GUI from tray error=tura_gui binary not found; set TURA_GUI_BIN to the desktop GUI executable

Starting tura_router manually also does not change the GUI state.

Expected behavior

Launching the desktop GUI should locate and start the installed gateway, or attach to an already-running healthy gateway automatically.

If tura_gateway is started manually and reports healthy on the default URL, the GUI should detect it and continue loading.

The gateway tray should also locate the GUI installed at the conventional macOS application path:

/Applications/tura_gui.app/Contents/MacOS/tura_gui

This matches the documented behavior: “The desktop GUI starts or attaches to a local gateway as needed.”

https://github.com/Tura-AI/tura/blob/main/docs/start/how-to-start.md#start-the-desktop-gui

If discovery, health validation, or version compatibility fails, the GUI should display the underlying error instead of waiting indefinitely.

Actual behavior

There appear to be failures in both discovery directions:

1. The Finder-launched GUI does not locate or start the globally installed npm gateway.
2. Even after tura_gateway is manually started and its health endpoint returns healthy, the GUI remains stuck at “Waiting for Gateway health...”.
3. The running gateway cannot locate the GUI installed under /Applications when the GUI is requested from its tray.
4. Starting tura_router manually does not help.

The GUI provides no error details, retry controls, backend-path selection, or installation guidance.

Frequency

Every time

Last known working version

No response

Sanitized evidence

Manual gateway startup:

🚀 Gateway server starting on http://127.0.0.1:4126
📡 Health check: http://127.0.0.1:4126/global/health
🔐 OAuth callback listening on http://127.0.0.1:1455/auth/callback
⏱️ Gateway startup ready in 0.08s

Sanitized health response:

{
"healthy": true,
"version": "0.1.0"
}

Notably, the health endpoint reports version 0.1.0 while the installed GUI and npm package are version 0.1.34. It is unclear whether this is an API version or an incorrect application version, but it may be relevant to the GUI’s health/compatibility check.

Gateway tray warning:

WARN gateway::tray: failed to open Tura GUI from tray
error=tura_gui binary not found; set TURA_GUI_BIN to the desktop GUI executable

Observed process tree after starting tura_gateway manually:

tura_gateway
└── tura_router serve-socket
└── tura_session_db

TCP 127.0.0.1:4126 is listening and /global/health returns healthy, but the GUI continues displaying:

Waiting for Gateway health...

Running a separate plain tura_router process did not change the result and should not be necessary because the gateway had already started tura_router serve-socket.

Checks

• I searched existing issues and found no duplicate.
• I removed credentials and private session data.

[Yohjisakamoto]

Hi, I tried to repeat this issue with git action. https://github.com/Tura-AI/tura/actions/runs/30474711624

I used the new 0.1.35 release and couldn't repeat this issue. Could you try to install the new 0.1.35 repease and see if the bug still exist?

[ManPetrauskas]

Unfortunately issue still persists. Hopefully somebody else can also weigh in with an arm Mac device.