[BUG] Connection Origin always shows Default after reopening host editor

Title

Connection Origin always shows Default after reopening host editor

Platform

Desktop App - Windows

Server Installation Method

Docker

Version

Beta 2.8.0 (in 2.7.1 too)

CLI Installation Method

None

CLI Version

No response

Troubleshooting

• I have examined logs and tried to find the issue
• I have reviewed opened and closed issues
• I have tried restarting the application
• I have checked open issues and ensured this is not a duplicate

The Problem

In the Windows Desktop app, the per-host "Connection Origin" setting is saved correctly, but after reopening the host editor it always shows "Default".

Selecting either "This Device" or "Remote Server" and saving the host works correctly. The local Desktop API also returns the saved value correctly as:

connectionOrigin: "local"

or:

connectionOrigin: "remote"

The problem occurs while converting the API host object to the Host Manager UI model.

In the current Beta bundle, the relevant mapper is minified as zt() in:

HostManagerData-D2rRIU9z.js

The returned object contains fields such as syncId, isShared, wolBroadcastAddress, etc., but connectionOrigin is not copied.

The host editor later initializes its form using:

connectionOrigin: e?.connectionOrigin ?? null

Because the Host Manager object no longer contains the property, it becomes null, so the UI displays "Default".

How to Reproduce

1. Open Termix Desktop on Windows.
2. Edit an SSH host.
3. Set "Connection Origin" to "This Device".
4. Save the host.
5. Reopen the same host.
6. "Connection Origin" is displayed as "Default".

The same happens when selecting "Remote Server".

Additional Context

The backend does not appear to be the cause.

I verified the local Desktop API response before and after saving the host. The saved value remains present there, for example:

connectionOrigin: "local"

However, the Host Manager UI object created from that API response does not contain the connectionOrigin property.

In the current Beta compiled bundle, the host-to-UI mapper is minified as zt() in HostManagerData-D2rRIU9z.js.

A relevant part of the current mapped object looks like this:

macAddress: e.macAddress,
wolBroadcastAddress: e.wolBroadcastAddress,
enableSsh: ...

There is no connectionOrigin property.

The source-level fix should be equivalent to:

macAddress: host.macAddress,
wolBroadcastAddress: host.wolBroadcastAddress,
connectionOrigin: host.connectionOrigin ?? null,
enableSsh: ...

I tested this locally by patching the compiled Beta bundle so that the mapper also preserves connectionOrigin.

After the patch:

• "This Device" remains selected after saving and reopening the host.
• "Remote Server" remains selected after saving and reopening the host.
• The existing wolBroadcastAddress field is also preserved.

Therefore the issue appears to be limited to the Host Manager host-to-UI mapping layer; no backend change is required.

Start with HostManagerData-D2rRIU9z.js and inspect the minified zt() host-to-UI mapper, comparing it with the local Desktop API response. Verify the host editor's connectionOrigin initialization and reproduce the reopen flow on Windows. Done means saved "This Device" and "Remote Server" selections remain visible after reopening, with existing wolBroadcastAddress behavior preserved.