[Bug] New provider dialog shows misleading 'Provider config not found' (probe race + silent Name requirement)

[tommy0103]

Affected area

Desktop app

Installation method

Built from source

Lody version or commit

2acd511

Operating system

macOS 15 arm64 (platform-independent)

Agent or runtime

Builtin Kimi Code (any builtin provider type is likely affected)

What happened?

Creating a builtin provider in Settings → Agents shows a scary orange banner Provider config not found on this machine: <configId> that looks like the config was lost or the backend is broken, plus a Retry button. In reality two independent, mundane things are happening:

1. The dialog writes a draft agentConfig row with an empty name as soon as it opens, and immediately fires machine/acp-capabilities-refresh for it. The write travels via the local data plane while the probe reads via local-control RPC, so the probe can read state from before the draft write landed. The daemon answers Provider config not found on this machine: <id> (session-execution-service.ts), and the dialog latches that as the current error even though the row exists (verified in the machine Flock doc WAL 29 ms before the probe).
2. Independently, the Create button is disabled until Name is non-empty — correct form validation, but there is no hint that the empty Name is what blocks creation. Combined with the banner, the user reads the situation as "creation failed on the backend" rather than "I must type a name".

The misleading part is that a transient probe race is presented as a durable not-found error, and the actual blocker (missing name) is never surfaced as the reason Create is disabled.

What did you expect?

• A probe that loses the race against the draft write retries or is ignored — never surfaced as Provider config not found for a row that exists.
• The Name field marked as required (inline validation message), so the disabled Create button has an obvious reason.

How can we reproduce it?

1. Open Settings → Agents → New provider → pick a builtin type (e.g. Kimi Code).
2. Observe the Provider config not found on this machine: <id> banner appear while Name is still empty.
3. Note Create is disabled with no explanation; the banner invites a Retry instead.
4. Fill in a Name and/or click Retry — everything suddenly works, confirming the banner was transient.

How often does it happen?

Every time (race permitting; observed consistently on a local OSS composition).

Relevant log output

# machine Flock doc WAL: draft row written 14:42:48.447 (name: "")
["agentConfig","<id>"] = { agentType:"kimi", cliType:"builtin", name:"", runtimeOverrides:{...} }
# daemon log: capabilities-refresh processed 14:42:48.476 (29ms later) → responded not-found
Received message: machine/acp-capabilities-refresh

Additional context

Separately (same area, possibly same root cause worth checking): in the local OSS composition (no remote bridge), builtin provider auto-registration in apps/cli/src/lib/lody.ts never runs, because startBuiltinAgentRegistration is only invoked from attachRemoteBridge() and no bridge attaches in local mode. Whether that is intentional or an oversight is worth a maintainer decision; it is NOT the cause of the banner above (the row in question was created manually via the dialog).

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.

[Dante-dan]

I traced this to two adjacent preconditions in the new-provider flow:

• The dialog could persist and probe a draft while its required name was still empty, even though the shared config parser rejects an empty name.
• For a valid draft, the renderer commits the Machine Flock row before asking the daemon to probe; the daemon can still miss that row on its first replica read.

The reference fix disables every probe entry point until a trimmed name is present and shows the required-name error inline. On the daemon side, a first config miss now performs one bounded Machine Flock sync and re-reads the authoritative config before returning the existing not-found result. This keeps genuine absence bounded while covering the creation race.

Fixed commit: Dante-dan@1c61702

Validation completed on that commit:

• agent-config-dialog.test.tsx: 28/28 passed
• session-execution-service.test.ts: 105/105 passed
• @lody/components and lody typechecks passed
• docs check, focused Prettier check, and git diff --check passed

Feedback on the one-sync recovery boundary or the UI guard is welcome; I can continue refining the branch.