Bug: Agents/API key flow appears present but is unusable due to auth/session handoff

[flux300a]

Summary

The Agents / API key flow appears to be present in the web app, but it is not usable in practice. The app can fall back to an older/public shell, the Agents UI does not become usable, and the CLI auth flow does not complete.

This looks like an auth/session/token issue between index.network and protocol.index.network, not a missing feature.

What I expected

• https://index.network/agents should show the authenticated Agents page.
• I should be able to create a personal agent and generate an API key.
• index login / cli-auth should complete once a valid web session exists.

What happens instead

• The site can return to an older/public shell instead of a usable authenticated Agents page.
• The expected Agents / API Keys flow is not available in practice.
• cli-auth / CLI login does not advance into a usable authorization state.

Reproduction notes

1. Open https://index.network/agents
2. Try to reach the personal agent / API key flow
3. Try the CLI login flow (index login / cli-auth)

Observed behavior:

• The web UI does not reliably land on a usable authenticated Agents experience.
• The CLI auth flow does not complete as expected.

Technical clues

I inspected the frontend bundle and found that the feature does exist in the shipped app:

• routes exist for:
  • /agents
  • /agents/:id
  • /cli-auth
  • /oauth/callback
  • /onboarding
• the Agents UI code includes:
  • System Agents
  • Personal Agents
  • Register Agent
  • Generate Key
  • API Keys
  • Agent ID
  • revoke/delete flows

I also found the Agents API calls in the frontend:

• GET /agents
• POST /agents
• GET /agents/:id/tokens
• POST /agents/:id/tokens
• DELETE /agents/:id/tokens/:tokenId

The important detail is that the app shell is on index.network, but auth/API appear to run through https://protocol.index.network:

• auth client base URL points to https://protocol.index.network
• API calls go to https://protocol.index.network/api/...
• cli-auth attempts to redirect into https://protocol.index.network/api/auth/mcp/authorize...

This suggests the bug is likely in session/token issuance or auth state handoff between index.network and protocol.index.network.

Likely area to inspect

• web session detection on /cli-auth
• handoff from authenticated web session to protocol.index.network/api/auth/mcp/authorize
• JWT/session issuance on protocol.index.network
• any feature gating / provisioning that prevents authenticated accounts from seeing the Agents flow
• routing that may send users back to a public/older shell instead of the authenticated app

Extra note

This does not look like a localhost callback limitation on the client side. In my environment, Windows was able to reach the WSL localhost callback path successfully, so the main blocker appears to be upstream auth/session behavior rather than local loopback itself.