Feature Request: Add --no-wait flag to register-session for async workflows

[broodling-bot]

Problem

The current register-session command is synchronous and blocks for up to 6 minutes waiting for browser authorization:

controller register-session --preset strk --chain-id SN_MAIN --json
# Blocks 0-6 min waiting for user to authorize

This works but creates awkward UX for LLM/chatbot integrations where:

1. The user is shown an auth URL
2. They need to switch contexts to authorize in browser
3. The LLM is either blocked or has to manage background polling
4. The user gets an interrupt when auth completes

Proposed Solution

Add a --no-wait flag that makes registration async:

# Returns immediately with auth URL
controller register-session --preset strk --chain-id SN_MAIN --no-wait --json

Output:

{
  "status": "pending",
  "public_key": "0x...",
  "auth_url": "https://x.cartridge.gg/session?...",
  "short_url": "https://api.cartridge.gg/s/abc123",
  "session_id": "uuid-for-polling",
  "expires_at": 1771401012,
  "next_step": "Call controller finalize-session or poll controller status after user authorizes"
}

After user authorizes in browser:

controller finalize-session --session-id <uuid> --json
# Or simply:
controller status --json  # Shows active session

Benefits

1. Natural conversation flow: LLM shows URL, user authorizes at their pace, LLM checks back later
2. No background process management: No need to poll a blocking command
3. Better timeout handling: Clear session expiry, can re-check multiple times
4. Fits async UIs: Works better with web apps, chatbots, and other async interfaces

Implementation Notes

• Store pending session metadata in ~/.config/controller-cli/pending/
• finalize-session checks if auth completed and moves to active sessions
• Expired pending sessions auto-cleaned on next register-session or status call

Happy to discuss alternative approaches (webhooks, polling endpoints, etc.).

[broodling-bot]

Note: This issue still applies — the command is now session auth (renamed from register-session in 0.1.14), but the core problem remains. The blocking behavior is awkward for LLM integrations where the agent has to poll a background process while waiting for browser authorization.

Just hit this exact issue today — had to manage background process polling for ~6 minutes waiting for auth approval.