#217·lore

Desktop 0.10.0 cannot add an existing local repository against an unauthenticated server (worked in 0.9.3)

Author: ldnjin81Created Sep 19, 2026Updated Sep 19, 2026

Summary

In Lore Desktop 0.10.0, "Add an existing local repository" fails when the server runs without a [server.auth] block. The flow aborts at the auth step and nothing is added.

The CLI is unaffected: clone, status, commit, push, branch merge all work against the same server with the same repository.

This worked in Desktop 0.9.3 on the same machine and same server, which suggests a regression rather than an intentional requirement.

Environment

  • Lore Desktop: 0.10.0.0 (Windows 11, x86_64) — previously 0.9.3 on the same machine
  • Lore CLI: 0.10.0+1172-lore_v0.10.0__urc_main
  • loreserver: 0.10.0 (Linux x86_64)
  • Server config: no [server.auth] block at all (only QUIC certificate, local immutable/mutable stores, [topology] provider = "none")

Per the server configuration reference: "If it is absent, the services accept unauthenticated requests." — which matches the CLI behaviour.

Steps to reproduce

  1. Run loreserver with a config containing no [server.auth] section.
  2. lore clone lore://<server-ip>:41337/<repo> <path> — succeeds.
  3. Verify with the CLI: lore status reports the branch in sync (remote_available: 1, remote_authorized: 1).
  4. In Desktop: Add an existing local repository → select <path>.

Expected: the repository is added, as in 0.9.3. Actual: nothing is added.

Logs

0.10.0 — fails (main.log)

Invoke into Lore (repositoryConfigGet)
Invoke into Lore (authLocalUserInfo) args={"withIdentityToken":true}
  Lore SDK error [authLocalUserInfo] | LOG lore_revision::relay:
    Operation not supported: authentication requires a configured auth endpoint
      at lore\src\auth.rs:715:6
  COMPLETE failed status=9
Invoke into Lore (authLoginInteractive) args={"noBrowser":false}
  Lore SDK error [authLoginInteractive] | LOG lore_revision::relay:
    Operation not supported: No authentication configured on server
      at lore-revision\src\auth\login.rs:268:10
  COMPLETE failed status=9

No further calls follow. The SDK log (%LOCALAPPDATA%\Epic Games\lore\data\logs\lore.log) records no repository command at all for the attempt — the flow dies before touching the repository.

0.9.3 — succeeds, same machine and server (main.log)

Invoke into Lore (authLocalUserInfo) args={"withToken":true}
  Lore SDK error [authLocalUserInfo] | LOG lore_revision::relay:
    Operation not supported: authentication requires a configured auth endpoint
  COMPLETE failed status=18
Invoke into Lore (repositoryStatus)
Watching repository: <path>          <-- proceeds and registers the repository
Invoke into Lore (repositoryStatus)
Invoke into Lore (revisionInfo)

So 0.9.3 hit the same auth error, ignored it, and carried on. 0.10.0 instead follows up with authLoginInteractive and stops.

SDK log for a CLI command against the same server (works)

[lore_revision::repository] Using repository config identity: <user>
[lore_transport::connection] Server environment config: EnvironmentConfig { endpoint: None, config: None }
[lore_transport::connection] Unauthenticated server, no token exchange
[lore_credential::token_store] Load user token failed, no auth endpoint provided
[lore_transport::auth::exchange] Auth exchange failed, no user authentication token found for <user>
...
[lore_revision::repository::status] Branch is synchronized, remote LATEST <hash>, local LATEST <hash>
[lore::util] Finished command: lore::repository::status (0.01s)

The transport layer handles the unauthenticated server gracefully here (Unauthenticated server, no token exchange) and the command completes.

Ruled out

  • Stale Desktop state. Clearing repositories / lastLoadedRepositoryHash / repoLastUpdated / branches in redux_state (%APPDATA%\lore-desktop\app_state.db) and restarting makes no difference — the same two auth errors appear and the add still fails.
  • Repository health. The working tree is a fresh clone, in sync at revision 18, and fully usable from the CLI (including commit/push).
  • Server misconfiguration. The server intentionally has no auth configured, which the docs describe as a supported mode.

Note on the v0.10.0 release notes

The notes mention the C API rename with_tokenwith_identity_token (matching the argument change visible between the 0.9.3 and 0.10.0 logs above), but do not state that Desktop's "add repository" path now requires authentication. If the new behaviour is intentional, it would be worth documenting; otherwise the add flow probably should tolerate authLocalUserInfo failing on an unauthenticated server, as 0.9.3 did.