feat(agents2): plugin agent types on a new Agents2 page - #693

Register the bundled responder agent type

The enabled-by-default plugin registers only the Agents2 page. A repo-wide search of production sources finds no call to ctx.agents2.register, so the stock app always has an empty types() snapshot, hides the New agent action, and cannot create or run an agent; only tests register synthetic types. Register the promised responder here or ship another enabled bundled provider.

AGENTS.md reference: AGENTS.md:L94-L97

Useful? React with 👍 / 👎.

Not changing this one: the PR deliberately ships without an agent type (see the description, and commit 5ed469d). Real types come in follow-up plugins, and until one is installed the page shows an empty state.

Delete the credential before forgetting the identity

When OS credential deletion fails or is denied, update has already removed the identity from identities.json, so the command reports an error but the next launch prunes the local record while the private key remains orphaned in the credential store. Delete the credential first—or restore the identity on failure—so this destructive operation remains retryable.

AGENTS.md reference: AGENTS.md:L10-L12

Useful? React with 👍 / 👎.

Fixed in a86967d: remove now deletes the key first and forgets the identity only after that succeeds. Covered by a_failed_key_deletion_keeps_the_identity_for_a_retry.

Roll back native creation when local persistence fails

If writeRecords throws after native.commit—for example because localStorage is full, unavailable, or the plugin supplied a non-serializable config—the native identity and key have already been committed but no record exists. Subsequent loads retain that identity while never displaying it, leaving an agent that cannot be managed or deleted through the page. Validate persistence before committing where possible and remove the newly committed native identity if the record write fails.

AGENTS.md reference: AGENTS.md:L10-L12

Useful? React with 👍 / 👎.

Fixed in a86967d: the local record is written before native.commit, so a quota or serialization failure happens before anything is committed. If native commit fails afterwards, the record stays. It is hidden while it has no identity, it lets the owner manage any identity native may have left behind, and the next load prunes it if there is none.

Fence creation against relay-session changes

If the user changes community or account while native authorization or commit is pending, creation continues using the captured old binding, but this.write reconciles against the new binding. The new identity is therefore persisted for the old community, this.find(pubkey) returns undefined, and the page's onCreated path then fails while an unexpected hidden agent remains. Recheck the session/scope after each awaited native step and clean up a committed identity when its originating binding has retired.

AGENTS.md reference: AGENTS.md:L89-L92

Useful? React with 👍 / 👎.

Addressed in a86967d, following the smaller fix from the other thread: create returns the committed agent built from its identity and record, without depending on the current snapshot. The agent stays saved in the community it was created for, and the page opens it only if agents2.find still sees it; otherwise it goes back to the grid. Covered by returns the created agent after the community changes mid-create.

Keep recognizing agents whose type plugin is unavailable

When an agent-type plugin is disabled or unloaded, the saved agent still exists but this hook returns undefined solely because its type lookup failed. The profile panel consequently treats the identity as a harness agent, exposes harness-only tabs such as Memories, and omits even the host-owned Attention section, despite the Agents2 page explicitly supporting unavailable types. Return the agent with an optional type so the panel preserves Agents2 behavior across plugin lifecycle changes.

AGENTS.md reference: AGENTS.md:L89-L92

Useful? React with 👍 / 👎.

Fixed in a86967d: useAgent2 returns { agent, type } with an optional type, so the panel keeps Attention and hides Memories. Covered in react.test.tsx.

[P2] Retain the identity until credential deletion succeeds

update writes the identity removal before credentials.delete runs. A denied/busy/unavailable credential store therefore leaves the key behind but removes the only persisted mapping needed to delete it. The dialog offers a retry, yet the next call takes None => Ok(()), so the UI reports deletion without attempting to remove that key again. Keep the identity (or a retryable deletion record) until exact-key deletion succeeds; cover a failing deletion followed by retry.

Fixed in a86967d: the key is deleted before the identity is forgotten, so a refused delete keeps the mapping and Retry deletes the key again. Covered by a_failed_key_deletion_keeps_the_identity_for_a_retry (a failed delete, then a retry).

[P2] Preserve recovery when saving a new identity fails

After credentials.add succeeds, either readback or the identity-file write can fail. The key remains in OS storage, while app_agent_create_commit has already removed the prepared request from its pending list and consumes it here. Retrying Create generates a different key; the previous key has neither an identity entry nor a retry path. Retain the same prepared identity for a retry, or compensate the key write and retain recovery information if cleanup fails. Add fault coverage after key storage and before identity persistence.

Fixed in a86967d: commit now saves the identity before the key. If the add or readback fails, it deletes the key and withdraws the identity only once the delete succeeds. If the delete fails too, the identity stays so remove can retry. Fault coverage is in a_failed_key_save_leaves_no_orphaned_key (add refused, readback refused, readback and delete refused).

[P2] Recover a committed identity when the local record write fails

The native identity/key are already durable when write calls localStorage.setItem. A quota/storage error rejects Create, but there is no rollback or recoverable record: after restart, update ignores that native identity because it has no local record, so the owner cannot manage/delete it through Agents2. write also mutates this.records before persistence, allowing a later update to expose the failed write in the current session. Make creation recoverable across this boundary (persist a recoverable record or compensate the native commit), and only replace the in-memory record map after a successful storage write.

Fixed in a86967d: the record is persisted before native commit, so every committed identity has a record to manage it by. write now replaces this.records only after setItem succeeds. Covered by commits no identity when its record cannot be saved and keeps the record of a create whose native commit fails….

[P2] Do not resolve Create from the currently selected community

A community switch or disconnect while native commit/profile publication is pending clears or changes the visible snapshot. The identity and record can still be saved successfully in the original community, but find(pubkey) then returns undefined; the assertion does not change that at runtime. Agents2Page immediately reads agent.pubkey, so the completion throws instead of returning the agent; a still-mounted create form treats that as a failure and offers another Create. Return the committed result independently of the current filtered snapshot, and suppress stale navigation in the page when its creation scope/opening has changed. Cover a switch during the awaited operations.

Fixed in a86967d: create returns the committed agent independently of the filtered snapshot. onCreated opens Build only when the agent is in the community still shown (it checks live with agents2.find) and otherwise returns to the grid. Tests: returns the created agent after the community changes mid-create (service) and stays on the grid when the new agent belongs to a community no longer shown (page).

[P2] Recognize saved Agents2 agents without an active type plugin

Disabling/removing a type plugin makes this hook return undefined even though agents2.find(pubkey) still returns the saved agent. ProfilePanel then omits the app-owned Attention tab and can show the harness Memories tab for that identity. This also happens during plugin replacement. Return the agent with an optional type: agentSections already accepts an unavailable type and can keep Attention usable, just as the Agents2 Build view does. Cover a saved agent whose type is disabled.

Fixed in a86967d: useAgent2 returns the saved agent with an optional type. agentSections already handles an unavailable type, so the profile panel keeps Attention and never shows Memories for it. Covered in react.test.tsx.

[P2] Prevent Escape from committing the cancelled rename

setDraft(name) is queued, but blur() synchronously dispatches onBlur={commit} before this handler finishes. That callback still closes over the edited draft, so Escape saves the name it was meant to discard. The local reset can then be overwritten again by the saved agent update. Suppress the blur commit for this cancellation (or make it read the reset value synchronously), and add a keyboard regression asserting that Escape never calls onSave.

Fixed in a86967d: Escape sets a ref that the blur handler checks, so it skips that one save. Regression test: saves a rename on Enter and discards it on Escape checks that onSave is never called on Escape.

[P2] Reserve skipped slugs when choosing a new object ID

readRecords moves invalid/over-limit objects into agent.skipped, but new-object naming checks only agent.attention. If a skipped watch/messages exists, Add watch with its default name reuses that slug; setAttention removes the skipped object and replaces its saved value without the owner choosing Fix or Remove. The same issue affects interests and timers. Check both attention and skipped keys when selecting a free slug, with coverage showing that adding a new object preserves a skipped object of the same stem.

Fixed in a86967d: freeSlug now treats both attention and skipped slugs as taken. Covered by never names a new object after a skipped one it would replace (a skipped watch/messages leads to watch/messages-2).

[P2] Coalesce pending timer occurrences and revalidate them before execution

nextDue advances when a job is enqueued, even if that timer's previous run is still holding the runner. Every later tick queues another occurrence, and drain executes all of them without checking the current timer. I reproduced this against this head with a 1-second timer expiring at +30s: hold its first run, remove the timer at +55s, then release the run. Start offsets were [5000, 55100, 55100, 55100, 55100] ms: four back-to-back runs after both expiry and deletion. This violates the promised no-burst schedule and lets removed automation continue acting.

Keep at most one outstanding occurrence per timer, advance the next schedule relative to actual execution, and before starting queued timer work recheck that the current timer still exists, is enabled, and is unexpired. Cover a held run spanning several intervals plus expiry/removal.

[P2] Handle credential contention before dropping an agent publication

Every publish calls read_key on the same Arc<PlatformCredentials> shared by all Agents2 agents. On macOS, this reaches Bundle::access, whose mutex try_lock fails immediately with Credentials are busy; the cross-process bundle lock also uses try_lock. The existing same_process_contention_reports_busy_without_blame_or_keychain_access test explicitly encodes that behavior.

Two agents responding concurrently (or a response overlapping agent creation/harness startup) therefore cause one publish to fail before HTTP dispatch whenever their credential operations overlap. This command propagates the error, and the runner only logs it; there is no retry/outbox for the lost reply. Serialize or boundedly retry the credential-acquisition phase, preserving exact identity/deletion checks. Do not blindly retry the later HTTP phase, where acceptance may be ambiguous. Add a gated contention test proving both publications reach dispatch. This is a source-traced integration defect; I did not exercise live Keychain access.

🤖 Cold reads are covered now (79efed31). AppAgentHost::key retries a Credentials are busy read every 100 ms for up to 5 s before dispatch. It releases the key-cache lock between attempts, so agents whose keys are already cached never wait. Any other refusal fails immediately, and the HTTP phase is never retried. Test: app_agents::tests::a_first_key_read_waits_out_a_busy_store.

[P3, optional] Preserve ordering when replacing the agent profile

A rename publishes kind 0 through Secret::signed, which uses the current wall-clock second without advancing past the previous profile. Two renames within one second can therefore leave the first name current under the lowest-event-ID tie break; a backwards clock adjustment has the same problem. The local name is already saved, so other users can continue seeing the old name. The existing harness profile flow handles this with current-profile lookup, sign_event_after, and confirmation. Reuse that replacement-ordering contract here. This is lower priority than the runtime blockers; it was source-traced, not exercised against a relay.

[P3, optional] Disclose that “Every channel” also includes global events

The “Any event” / “Every channel it can read” combination stores channels: "all", kinds: []. watchMatches then skips the h check entirely, while subscribeLive also supplies presence, profiles, read-state, and other non-channel routes. A focused service probe with one read-state event, 70 presence events, and an addressed message produced 33 watch runs and dropped the mention because these share the same queue.

If channels: "all" intentionally includes global traffic, label/disclose that scope rather than presenting it as channel-only; otherwise constrain this UI selection to channel events. I could not locate attention spec r16 in the repository or PR, so this is a UI/intent clarification, not a demand to change the protocol semantics.

[P2] Fence key deletion when the relay session retires

If the community is switched or disconnected while archives.ensure() / refresh() is pending, session disposal aborts that read but its promise resolves. state() then becomes unknown, and the closed archive service’s consent() returns null. This code treats that as an agent without a profile and proceeds to native.remove, permanently deleting the key without confirming archival. The timeout signal is not tied to session lifetime, and the initial binding check is never repeated. Revalidate the captured binding/session after awaited relay steps and immediately before native deletion; distinguish a retired/unavailable archive service from a confirmed missing-profile case. Add a gated regression that retires the session during archive refresh and asserts the key/record remain available for retry.

[P2] Read a fresh profile before preserving its other fields

session.profiles.ensure() only fetches missing identities (profile-directory.ts:85–89); once this agent is cached, it performs no read. If another client/type updates the picture or about while the profile live route is recovering or its update has not arrived, renaming here republishes the older cached fields and overwrites that update. native.publish does no current-profile lookup or merge. Use a fresh, successful read of this agent’s current kind 0 as the replacement base, retaining profilePending on read failure rather than treating the display cache as authoritative. Add a regression with an already-cached profile and a newer relay profile whose non-name fields must survive the rename.

[P2] Hand off focus before a successful retry removes its button

A keyboard user can keep focus on Retry publishing while it is loading (the shared Button deliberately preserves focus). On success, sendProfile clears profilePending and notifies subscribers, so this return removes the focused button and its entire region. Neither this component nor AgentBuild transfers focus, leaving the user at the document rather than a stable agent control. Hand focus to a stable destination only if this retry still owns focus immediately before removal; do not steal focus if the user moved elsewhere. Cover pending, repeated failure, success and moving away during the request.

[P2] Give other due timers a turn before repeating the first

dueTimer always scans from the first attention entry and returns its first due timer. If that recurring timer's run lasts longer than its interval, it is already due again whenever drain calls this function, so a second enabled, overdue timer never runs—even with no queued events. The periodic tick cannot advance the second timer while the first run holds runner.running. Select the oldest due timer or rotate eligible timers while retaining the new expiry/removal checks and one-occurrence rule. Add a regression with two retained timers where the first run repeatedly exceeds its interval and assert that the second progresses.

🤖 Fixed in b9e56fee. dueTimer now picks the due timer that has waited longest (the earliest nextDue) instead of the first one in attention order. The expiry/removal checks and the one-waiting-occurrence rule are unchanged. Regression test: "gives each due timer a turn when one's runs outlast its interval". Each run takes three intervals, and the test asserts the two timers alternate. It fails on 7cda820.

[P2] Retry synchronization on the actual live-connection recovery path

This sync() runs only when the binding/session changes; refresh() is otherwise triggered by identity mutations. Normal WebSocket recovery happens inside the existing session (relay/live.ts reconnects and session.live notifies), without replacing RelayData.session or notifying this service through relay.subscribe. A transient failed profile publication or deletion cleanup therefore stays failed after the connection recovers, potentially indefinitely while the user keeps the community open. The publishing Retry control has also been removed. Subscribe to the existing live recovery signal, or retain an explicit visible retry; test recovery with the same session rather than the current fake's cloned session.

🤖 Fixed in b9e56fee and 79efed31. The service now subscribes to session.live and re-runs sync() whenever the status goes from not-connected back to connected in the same session. If a cleanup is still running when that happens, it runs again if that attempt fails. The fake session now has a live status, and recover() drops and restores it without replacing the session. Tests: "retries a failed profile and cleanup when the live connection recovers in the same session" and "retries a cleanup that fails after the connection recovered while it ran". Both fail without the fix.

[P2] Settle the first profile publication before forgetting a deleted identity

Create now returns while sync()'s native profile POST is still in flight. Delete removes the cached key, but the running app_agent_publish_profile already owns an Arc<Secret> and its HTTP request is neither cancelled nor joined. For a non-admin owner, cleanup can read no profile yet, get null consent, and forget the tombstone; the delayed initial POST can then be accepted and leave the deleted agent visible in the directory with no cleanup record left. Keep the tombstone and coordinate with already-admitted profile publication before treating profile absence as final, then perform the archive decision. Cover a held first profile POST completing after Delete starts; immediate key removal can remain unchanged.

🤖 Fixed in b9e56fee. The profile lock is now per agent, and native Delete takes that agent's lock before it removes the key. A profile POST already in flight therefore finishes (accepted or refused) before Delete returns, and before cleanup reads the profile to decide on archiving. The tombstone handling is unchanged. Rust test: app_agents::tests::delete_waits_for_a_profile_publication_in_flight, which fails if the lock is removed. One edge is still open: a POST that times out client-side after the relay already accepted it.

[P2] Hand the queued cleanup retry to the current binding

The new again flag is discarded when the old binding was cancelled: failed becomes false, so the retry requested by a replacement binding never runs. For example, cleanup can be awaiting archives.ensure()/refresh() (which do not take this cleanup signal) while the user switches away and returns to the community. Communities retain that session; the return calls sync(), records again = true, and leaves the old attempt running. When its archive read settles, throwIfAborted() reaches this branch and drops the pending retry. With the returned session already connected, no further recovery edge is guaranteed, leaving the deleted agent's archival unfinished until another unrelated refresh/reconnect.

After releasing the in-flight slot, honor a queued request using the current, non-aborted binding only if the tombstone still belongs to its owner/community; do not retry with the cancelled binding. Add a gated archive-read regression that returns to the community before the old attempt settles. This is the remaining overlap case of the earlier synchronization-recovery finding.

[P3, optional] Make the deletion-order regression independent of runner speed

This negative assertion assumes an unlocked delete of an absent agent completes within 300 ms. The test never observes the spawned task reaching the profile gate (or its spawn_blocking work), so a slow executor can make it pass even if the production lock is removed. Use an explicit admission/completion gate to establish the operation reached the boundary, assert it remains blocked, then release publication and verify deletion finishes. This is a test-evidence improvement, not an additional production blocker.