[Bug][macOS][multi-agent] Startup auth sync overwrites agent-local credentials; UI/session state can diverge from actual agent binding

[baixudong2026]

Summary

This is a consolidated multi-agent state-consistency report for the ClawX desktop app on macOS.

I am grouping these symptoms because they all occurred in the same current 0.5.x desktop workflow and they share a common user-facing failure: ClawX can maintain or display state that is different from the canonical per-agent state actually stored/routed by OpenClaw.

The most serious item is a reproducible credential-isolation regression: a secondary agent can hold its own API key while ClawX is stopped, but starting ClawX rewrites that agent's SQLite auth store with the main agent's key.

There are also UI/session consistency problems: after legitimate agent rebinding, the backend can be correctly bound to the new agent while the visual UI remains stale/ambiguous; and an existing conversation/session can be present in the underlying state but absent from the ClawX UI.

A separate packaged-app dependency failure (Cannot find module "jszip") was also observed during the same 0.5.x upgrade cycle and is included at the end as an additional packaging symptom.

Environment

• ClawX desktop app, macOS, Apple Silicon
• Current 0.5.x installation / packaged app
• Bundled OpenClaw runtime involved in the credential reproduction: 2026.7.1-2 (0790d9f)
• Multiple agents
• Custom OpenAI-compatible provider backed by DeepSeek
• Main and secondary agents intentionally use the same profile id but different per-agent API keys
• A messaging channel has also been legitimately rebound between multiple agents during normal use

No real API keys, key fingerprints, usernames, account IDs, machine-specific absolute paths, or personal data are included below.

---

A. P1: ClawX startup overwrites a secondary agent's API key

Reproduction

1. Fully quit ClawX.
2. Use the supported OpenClaw CLI path to write a distinct API key for a secondary agent:

models auth --agent <secondary> paste-api-key \
  --provider <provider> \
  --profile-id <provider>:default

3. While ClawX is still stopped, inspect the two agent-scoped SQLite stores.

Expected/verified before startup:

main      -> KEY_A
secondary -> KEY_B

4. Start ClawX.
5. Re-read the two agent-scoped SQLite auth_profile_store records.

Actual result:

main      -> KEY_A
secondary -> KEY_A

The two stores are rewritten in the same startup batch, only milliseconds apart. No model invocation is required.

This is not merely stale models.json state. The per-agent SQLite auth_profile_store.store_json itself changes.

Upstream review already confirmed the ClawX responsibility boundary

This was first reported upstream as:

• [Regression] ClawX startup overwrites per-agent API key in auth_profile_store on 2026.7.1-2 openclaw/openclaw#146511

OpenClaw's ClawSweeper review closed that issue as outside the OpenClaw source repository after source inspection identified the matching writer in ClawX. The review explicitly concluded that ClawX's startup synchronization can replace agent-local credentials across agents.

Relevant review comment:

• [Regression] ClawX startup overwrites per-agent API key in auth_profile_store on 2026.7.1-2 openclaw/openclaw#146511 (comment)

The reviewed ClawX path was:

1. electron/main/index.ts calls/awaits syncAllProviderAuthToRuntime() before Gateway startup.
2. electron/services/providers/provider-runtime-sync.ts reads saved provider secrets and calls saveProviderKeyToOpenClaw(...) without an agent id.
3. saveProviderKeyToOpenClaw supports an optional agent scope; without one, the reviewed implementation discovers configured agents and writes matching provider:default profiles broadly.
4. electron/utils/openclaw-auth-sqlite.ts persists the rewritten auth profile into SQLite.

The same global sync shape is still visible in current main in provider-runtime-sync.ts: syncAllProviderAuthToRuntime() loops provider accounts and calls saveProviderKeyToOpenClaw(runtimeProviderKey, secret.apiKey) without an explicit agent id.

Impact

• Per-agent credential isolation silently collapses after app startup.
• Usage/cost attribution between agents becomes unreliable.
• Provider rate-limit isolation between agents is defeated.
• The supported CLI appears to succeed, but ClawX later replaces the credential without warning.
• This is credential/config data loss, not only a display problem.

---

B. Agent binding works in the backend, but the UI can be stale or ambiguous

The channel binding history itself is normal usage: it was intentionally rebound from the main agent to one secondary agent and later to another secondary agent. Historical rebinding is not the bug.

The problem is that after the backend binding changes, the ClawX visual surface is not a reliable source of truth for the active/bound agent. In the observed case, a read-only audit and subsequent message routing confirmed that the backend was correctly bound to the latest secondary agent after restart, but the UI could still look like an earlier/default agent or fail to provide a clear visual way to verify and operate the binding.

This means a user cannot safely answer a basic question from the GUI alone: "Which agent is this conversation/channel actually connected to right now?"

Expected behavior:

• Every session/channel should have an explicit visible agent binding.
• Agent name/avatar/identity/workspace/model shown in the UI should be derived from the actual bound agent id.
• Rebinding should be possible and verifiable in the visual UI without manual JSON/plist/SQLite inspection.
• After rebinding, the UI should update immediately and remain consistent after restart.

Actual behavior:

• Backend routing can be correct while the visual representation is stale or ambiguous.
• Manual inspection/restart was required to establish which agent was actually receiving the messages.
• This makes multi-agent operation unsafe because the UI cannot be trusted as the control plane.

Related issue:

• [Bug]: 切换切换agent 失败，然后模型选择了，也没生效 #825 ([Bug]: ... agent ... model ...) was closed as completed in April, but the same class of UI/agent-selection inconsistency is still observable in the later 0.5.x multi-agent workflow, so this may be a regression or incomplete coverage.

---

C. Conversation/session exists in backend state but is missing from ClawX UI

A conversation used for system/tools work existed in the underlying state/session data, but the ClawX UI did not display it.

This is slightly different from a chat losing messages mid-turn: the important mismatch is that the session/conversation exists, but the desktop UI does not surface it.

Expected behavior:

• Valid backend sessions should be discoverable in the ClawX session/chat UI.
• The UI session list should reconcile against canonical backend state instead of silently omitting an existing conversation.
• Recovery should not require low-level filesystem/database inspection.

Actual behavior:

• The session can exist while the UI behaves as if it does not.

Related issue:

• [Bug]: Chat content disappears, requires restart to recover #709 (Chat content disappears, requires restart to recover) was closed as completed. This report is not exactly the same reproduction, but it indicates that frontend/session-state divergence still exists in the current multi-agent desktop workflow.

Also related:

• [Bug] Workspace browser shows default workspace files instead of agent-specific workspace #1209 documents another current multi-agent UI mismatch where the UI header can show a non-default agent while the Workspace browser displays the default agent's workspace. That issue is still open and is consistent with the broader concern that UI state is sometimes resolved independently of the actual agent-specific state.

---

D. Additional packaged-app failure observed in the same 0.5.x cycle: missing jszip

On a packaged macOS ClawX 0.5.x installation, the app previously failed to launch with an Electron main-process error equivalent to:

Cannot find module "jszip"

The failure originated from the packaged Electron main bundle and prevented normal startup. Reinstallation was required as a recovery step.

If this dependency/package issue has already been fixed in the latest build, this sub-item can be treated as historical/closed; I am including it because it occurred during the same current desktop upgrade/debugging cycle and made the application completely unavailable.

---

Expected fix / acceptance criteria

1. Preserve agent-local credential overrides. Startup provider synchronization must not broadcast one saved provider key across all agents and overwrite an existing agent-scoped credential.
2. If ClawX needs to seed provider credentials, only populate missing/default profiles or explicitly scoped targets; do not overwrite a secondary agent's existing local secret.
3. Add a regression test:

before ClawX start:
main=KEY_A, secondary=KEY_B

after ClawX start:
main=KEY_A, secondary=KEY_B

4. If ClawX has already overwritten an agent-local credential, surface a warning/recovery path instead of silently persisting the replacement.
5. Make session/channel -> agent binding explicit in the UI and derive displayed identity/workspace/model from the actual bound agent id.
6. Add UI tests for rebind + restart: main -> secondary A -> secondary B must remain visually and functionally consistent.
7. Reconcile the ClawX session list with canonical backend session state so valid sessions cannot silently disappear from the desktop UI.
8. Add packaged-app smoke tests that launch the real macOS bundle and fail CI when a runtime dependency such as jszip is missing.

Why I am filing this as a consolidated report

The credential overwrite is independently reproducible and source-reviewed. The UI/session symptoms are separate but materially related from the user's perspective: ClawX is the desktop control plane for a multi-agent system, so it must not both mutate agent-local state globally and present stale/ambiguous agent/session state in the GUI.

I can provide additional redacted logs or run a targeted diagnostic against the shipped ClawX artifact if maintainers need a narrower reproduction for any subsection.

[baixudong2026]

Upstream OpenClaw review update / handoff

I am forwarding the complete outcome of the upstream OpenClaw review for the credential-overwrite portion of this report so the evidence and responsibility boundary are preserved here in the ClawX issue.

Original upstream report: openclaw/openclaw#146511

The upstream review sequence was:

1. ClawSweeper review started for [Regression] ClawX startup overwrites per-agent API key in auth_profile_store on 2026.7.1-2.
2. The final review concluded that the observed overwrite belongs to ClawX's startup synchronization path outside the OpenClaw source repository, and that no independent OpenClaw Gateway failure was established.
3. The upstream issue was then closed as not planned because it is outside the OpenClaw repository boundary, not because the reported overwrite was disproven.

Final review comment:
openclaw/openclaw#146511 (comment)

Upstream review summary:

The report provides useful startup timing evidence, but ClawX owns a matching credential overwrite path outside this repository. No independent OpenClaw Gateway failure is established.

The review also states that the supported repair boundary is ClawX: agent-local credential overrides should be preserved during startup synchronization, and credentials previously replaced should have a visible recovery path.

Source-level findings from the upstream review

• Credential synchronization happens before Gateway startup. ClawX awaits syncAllProviderAuthToRuntime() before gatewayManager.start, which matches the observed overwrite occurring without any model invocation.
• Saved provider secrets are synchronized without an agent scope. syncAllProviderAuthToRuntime() calls saveProviderKeyToOpenClaw(...) without an agent ID.
• Matching profiles are therefore overwritten across configured agents. Without an explicit agent scope, saveProviderKeyToOpenClaw discovers configured agents and assigns the saved API key to matching provider:default profiles before persisting them.
• The overwrite reaches SQLite itself. ClawX's persistence helper updates auth_profile_store.store_json directly, so this is not merely stale/generated models.json state.
• The review classified this as a medium security concern because external startup synchronization can replace credential identity across agents and undermine intended credential/billing separation. The review's confidence for this finding was 0.98.

Relevant ClawX paths identified by the upstream review:

• electron/main/index.ts — startup ordering around syncAllProviderAuthToRuntime()
• electron/services/providers/provider-runtime-sync.ts — global provider-secret synchronization
• electron/utils/openclaw-auth.ts — broad saveProviderKeyToOpenClaw behavior when no agent ID is supplied
• electron/utils/openclaw-auth-sqlite.ts — direct persistence into auth_profile_store

For clarity, the upstream closure should therefore be read as a repository handoff to ClawX, not as a rejection of the reproduction. The user-visible reproduction remains:

before ClawX start:
main      -> KEY_A
secondary -> KEY_B

after ClawX start:
main      -> KEY_A
secondary -> KEY_A

No real API keys or personal machine-specific data are included here. I can provide additional redacted timing evidence or run a narrower diagnostic if maintainers need it.