Cloud: a new chat offers Sign in from its first turn (agent_login before the first send)

TE
5d ago
+36-5

Fixes #30894.

Leo, 2026-11-01, on the Cloud sign-in card: "yes those are important".

A new Cloud chat had no sign-in offer on its first failed turn. Its wire (RemoteAcpmuxWire(start:)) has no session client during initialize, so it never named agent_login. The page reads features only at initialize, so the offer stayed hidden until the chat reconnected.

The fix:

  • AgentTabs+Wiring: sets the host's servesLogin from the machine daemon's agent-session-login-v1, the same read that servesTrust and servesKeyedReason already use.
  • AgentTabRemoteHost: passes it to the start wire.
  • RemoteAcpmuxWire: names agent_login from it until a session client exists, then asks the client as before.

Test: RemoteAcpmuxLoginTests.aNewChatNamesTheFeatureBeforeItsFirstSend covers a new chat whose daemon serves the relay and one whose daemon doesn't, each with and without a Cloud owner answer.

Risk: low. An observer never takes the start route, and a wire that already has a session is unchanged.

Agent session: agent session

🤖 Generated with Claude Code


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need.


Summary by cubic

Fixes #30894. A new Cloud chat now offers Sign in from its first failed turn; previously the offer appeared only after the chat reconnected, because the start wire has no session client during initialize and so never named agent_login.

  • AgentTabs+Wiring sets the host's servesLogin from the daemon's agent-session-login-v1, the same read that servesTrust and servesKeyedReason use.
  • AgentTabRemoteHost passes that flag to the start wire, and RemoteAcpmuxWire names agent_login from it until a session client exists.
  • A wire that already has a session keeps asking its client, so existing behavior is unchanged.
  • Adds a test covering new chats with and without a serving daemon, each with and without a Cloud owner answer.