T3 Code Desktop 0.0.23 fails SSH environment pairing due to DateTime schema mismatch

[fionn77]

Summary

T3 Code Desktop 0.0.23 on Windows fails when adding an SSH environment because the desktop app decodes JSON API timestamp strings with
Schema.DateTimeUtc instead of Schema.DateTimeUtcFromString.

This causes SSH bearer session bootstrap to fail even though the remote T3 server returns HTTP 200 with a valid JSON response.

Environment

• App: T3 Code (Alpha)
• Version: 0.0.23
• OS: Windows
• Flow: Add SSH environment

Error

Error invoking remote method 'desktop:bootstrap-ssh-bearer-session':
DesktopSshRemoteApiError: SSH remote API request failed during bootstrap-bearer-session

Desktop logs include:

SchemaError: Expected DateTime.Utc, got "2026-06-11T19:02:03.848Z"
    at ["expiresAt"]

### Remote API response

The remote server returns HTTP 200 for:

/api/auth/bootstrap/bearer

With JSON similar to:

{
  "authenticated": true,
  "role": "client",
  "sessionMethod": "bearer-session-token",
  "expiresAt": "2026-06-11T19:03:20.007Z",
  "sessionToken": "..."
}

### Root Cause

The desktop bundle defines auth response schemas using Schema.DateTimeUtc for fields that are decoded from HTTP JSON responses.

Because JSON timestamps arrive as strings, these fields should use Schema.DateTimeUtcFromString.

In the bundled desktop file:

apps/desktop/dist-electron/main.cjs

The affected schema included:

const AuthBearerBootstrapResult = Schema.Struct({
  authenticated: Schema.Literal(true),
  role: AuthSessionRole,
  sessionMethod: Schema.Literal("bearer-session-token"),
  expiresAt: Schema.DateTimeUtc,
  sessionToken: TrimmedNonEmptyString
});

This rejects the valid JSON string returned by the server.

### Expected Behavior

SSH environment pairing should succeed when the remote server returns a valid ISO timestamp string in expiresAt.

### Actual Behavior

Pairing fails during bearer session bootstrap because the desktop app expects an already-materialized DateTime.Utc value instead of a
JSON string.

### Local Workaround Verified

I patched the installed Windows app.asar locally and changed the relevant JSON response timestamp fields from:

Schema.DateTimeUtc

to:

Schema.DateTimeUtcFromString

After patching, SSH environment pairing worked.

The fields patched locally were:

- AuthBootstrapResult.expiresAt
- AuthBearerBootstrapResult.expiresAt
- AuthWebSocketTokenResult.expiresAt
- AuthPairingCredentialResult.expiresAt
- AuthPairingLink.createdAt
- AuthPairingLink.expiresAt
- AuthClientSession.issuedAt
- AuthClientSession.expiresAt
- AuthClientSession.lastConnectedAt
- AuthSessionState.expiresAt

### Suggested Fix

For schemas used to decode HTTP JSON API responses, replace timestamp fields using:

Schema.DateTimeUtc

with:

Schema.DateTimeUtcFromString

This should align the desktop decoder with normal JSON API behavior, where dates are serialized as ISO strings.

[gthay]

I can reproduce the same issue on macOS with T3 Code Desktop 0.0.23.

Environment:

• App: T3 Code (Alpha)
• Version: 0.0.23
• OS: macOS
• Remote host: Ubuntu VPS
• Remote T3 server: t3 v0.0.23
• Flow: Settings -> Connections -> Remote Environments -> Add environment -> SSH launch

Error:

Error invoking remote method 'desktop:bootstrap-ssh-bearer-session':
DesktopSshRemoteApiError: SSH remote API request failed during bootstrap-bearer-session.

Desktop trace shows the same schema failure:

SchemaError: Expected DateTime.Utc, got "2026-06-13T02:48:40.149Z"
at ["expiresAt"]

Important detail: SSH and the tunnel were working. The remote server received the request through the local forwarded port and returned HTTP 200 for:

POST /api/auth/bootstrap/bearer

Remote trace showed:

http.response.status_code: 200
http.response.header.content-type: application/json

The response shape was:

{
  "authenticated": true,
  "role": "client",
  "sessionMethod": "bearer-session-token",
  "expiresAt": "2026-06-13T02:48:40.149Z",
  "sessionToken": "..."
}

So this is not an SSH auth/tunnel failure. It is the desktop app rejecting a valid JSON response because expiresAt is decoded with Schema.DateTimeUtc instead of a JSON-string decoder like Schema.DateTimeUtcFromString.

I also verified a workaround: running the remote T3 server manually on the VPS loopback interface and using a normal SSH LocalForward plus pairing URL works, because it avoids the desktop-managed SSH bearer bootstrap path.