Session Recovery and Skip OAuth Flow

Automatic Session Recovery After Satellite Restart

When a satellite restarted — for an update, scaling event, or recovery — all active MCP sessions were lost. Clients like Claude Code would hit a "Server not initialized" error on their next tool call, and the only fix was to manually reconnect.

The satellite already had session resurrection logic that detected stale session IDs and tried to recreate them. But the bootstrap step that marks a session as "initialized" was silently failing. An internal mock used during bootstrap was missing a required interface, causing the MCP SDK to error out before it could finish.

We fixed the bootstrap process so it completes correctly. Now when a satellite restarts:

1. Your next tool call arrives with the old session ID
2. The satellite detects the stale session and creates a fresh one with the same ID
3. The bootstrap runs successfully, marking the session as initialized
4. Your tool call goes through as if nothing happened

No reconnection needed. No error messages. Your workflow continues uninterrupted.

SSE reconnections also recover the same way — if your client reconnects its event stream after a restart, the session comes back automatically. And DELETE requests for sessions that no longer exist now return a clean success response instead of an error.

This matters most for teams running satellites that receive regular updates or operate in environments with automatic scaling.

Skip OAuth Flow for MCP Servers

Some MCP servers support OAuth for authentication. When DeployStack detects an OAuth provider on an HTTP or SSE server, it walks the user through an authorization flow — redirect to the provider, grant access, get tokens back. That works great for services where OAuth is the only option.

But not every server needs it. GitHub's MCP server, for example, supports OAuth and accepts a plain Bearer token. If a team already has a Personal Access Token (PAT), the OAuth redirect is extra steps for no reason. The same goes for internal APIs behind a gateway that hands out static tokens.

The New Toggle

The MCP server catalog now has a Skip OAuth Flow toggle in the Basic Info step. When a global admin enables it, DeployStack won't start the OAuth authorization flow for that server — even if OAuth credentials are configured on it.

Instead, teams install the server and provide their Bearer token or PAT directly in the headers field. The token gets stored securely in DeployStack's credential vault, same as any other server header.

When to Use It

Turn this on when:

• The MCP server accepts static Bearer tokens (like a GitHub PAT)
• Your teams already have tokens and don't need the OAuth consent screen
• You're connecting to an internal API that uses pre-issued tokens

Leave it off when the server genuinely requires the OAuth flow — for example, when users need to authorize with their own accounts on a third-party service.

How It Works

1. Admin configures the server — In the MCP catalog, the admin adds or edits an HTTP/SSE server and enables the "Skip OAuth Flow" toggle.
2. OAuth detection is bypassed — When a team installs that server, DeployStack sees the flag and skips the OAuth authorization redirect entirely. No consent screen, no callback, no token exchange.
3. Team provides a token — During installation, team members enter their Bearer token or PAT in the server's headers configuration. DeployStack stores it encrypted in the credential vault.
4. Satellite uses the token — When the satellite connects to the MCP server, it sends the token as a standard Authorization header. The server treats it like any other authenticated request.

Nothing Changes If You Don't Need It

The toggle defaults to off. All existing servers keep their current authentication behavior. OAuth flows that are already set up continue to work exactly as before.