Codex provider falls back to providerDisconnected after app-server timeouts (thread/list, thread/read)

[Yinghai75]

Summary

On current Farfield (@farfield/server 0.2.2), the Codex provider can become unusable after app-server requests start timing out. Once that happens, Farfield marks Codex as providerDisconnected, and both thread list sync and thread reads stop working.

This appears to be more than a UI issue. The underlying problem is app-server instability / timeouts, and providerDisconnected is the resulting state exposed by the UI.

Environment

• Farfield server: @farfield/server 0.2.2
• Codex desktop app on macOS
• Reproduced on local desktop setup
• Date observed: 2026-03-07 (Beijing time)

Symptoms in UI

Farfield starts showing errors like:

• Feature readThread is unavailable for codex (providerDisconnected)
• Thread list sync failed for provider(s): Codex: Feature listThreads is unavailable for codex (providerDisconnected)

The status panel shows a state like:

• Codex: disconnected
• App: not ready
• IPC: connected
• Init: ready
• Error: app-server request timed out: thread/read

What I observed from /api/health

At failure time the server reports:

{
  "ok": true,
  "state": {
    "appReady": false,
    "ipcConnected": true,
    "ipcInitialized": true,
    "codexAvailable": true,
    "lastError": "app-server request timed out: thread/read"
  }
}

After restarting Farfield, it can briefly recover to appReady: true, but then it falls back again. On the next failure cycle I also saw:

• lastError: app-server request timed out: thread/list
• repeated account/rateLimits/read timeouts

Relevant log lines

Examples from ~/Library/Logs/farfield.log:

provider=codex error="app-server request timed out: thread/list" msg="unified-sidebar-threads-failed"
provider=codex error="Feature listThreads is unavailable for codex (providerDisconnected)" msg="unified-sidebar-threads-failed"
error="app-server request timed out: account/rateLimits/read" msg="rate-limits-read-failed"

I also simultaneously see stream parse failures such as:

ThreadStreamStateChangedBroadcast did not match expected schema ... explanation: Expected string, received null

but the more serious blocker is the app-server timeout path, because once that happens the whole Codex provider becomes unavailable.

Expected behavior

• A slow or timed-out app-server request should not permanently collapse Codex into providerDisconnected so aggressively
• If possible, transient failures should degrade more gracefully and allow later retries to recover without the provider effectively disappearing

Actual behavior

• thread/read or thread/list times out
• appReady flips to false
• feature availability becomes providerDisconnected
• thread list sync and thread reads stop working

Additional note

I did not find an existing issue specifically tracking the providerDisconnected <- app-server timeout (thread/list / thread/read) path, so opening this as a dedicated blocker report.

[SHAREN]

One debugging note from my side: some of my early observations were confusing because I was not actually hitting the backend I thought I was testing.

Tailscale was still routing to an older cached npx @farfield/server process instead of the repo server. I fixed that by stopping the stale process, starting the local repo server via run-farfield.ps1, and pointing Tailscale Serve back to http://127.0.0.1:4311.

After that, I was able to verify behavior against the intended backend. Mentioning this only because a stale process/route mismatch can make this issue look inconsistent during debugging.