fix(connect): correct self-host copy in claim-code disabled state (TASK-1525 follow-up) (#587)

The `claim_disabled` path only fires on self-host deployments without
PAD_MCP_PUBLIC_URL — the OAuth server (and with it the claim secret
and the OAuth-grant model itself) only mounts under that env var. In
that configuration:

  - Agents authenticate as the user via session tokens from
    ~/.pad/credentials.json — stdio MCP (`pad mcp serve`) and the
    CLI both inherit it.
  - The agent sees every workspace the user is a member of by
    default. There is no per-workspace OAuth grant to claim into.
  - /console/connected-apps is empty by definition (it lists OAuth
    grants).

So the prior copy ("Use the MCP tab to authorize an agent from
scratch") was misdirection on two counts:

  1. The MCP tab is filtered out entirely when mcpPublicUrl is empty
     (visibleTabs). The button it pointed at didn't exist.
  2. There's no further "setup" required — the agent already has
     access.

Two fixes:

  - Rewrite the disabled-state copy to tell self-host users they're
    already done: "No claim code needed on this deployment. Agents
    connected via the CLI or stdio MCP use your user session and
    already have access to every workspace you're a member of."
  - Hide the "Connected agents →" footer link when mcpPublicUrl is
    empty so we don't point self-host users at an empty page.

The Open Connected apps link inside the suppression-state panel
stays — suppression only fires when an active OAuth grant covers
the workspace, which by definition only happens on cloud / remote-
MCP-enabled deployments.
This commit is contained in:
xarmian
2026-05-18 10:49:19 -04:00
committed by GitHub
parent fc6afd01be
commit ab5b68c7c3
@@ -350,22 +350,25 @@
</a>
</div>
{:else if claimState.kind === 'disabled'}
<!--
"claim_disabled" only fires on self-host deployments
that don't have `PAD_MCP_PUBLIC_URL` wired — the
OAuth server (and with it the claim secret) only
mounts under that env var. In that configuration
agents connect via stdio MCP (`pad mcp serve`) or
the CLI, both of which inherit the user's session
token from ~/.pad/credentials.json and see every
workspace the user is a member of. There IS no
per-workspace OAuth grant to claim into — so the
right copy doesn't redirect users to "set something
up", it tells them they're already done.
-->
<div class="info-panel">
<p class="info-panel-body">
Claim codes arent available on this deployment. Use the
<button
class="inline-link-btn"
type="button"
onclick={() => mcpPublicUrl && (activeTab = 'mcp')}
disabled={!mcpPublicUrl}
>MCP tab</button>
to authorize an agent from scratch, or the
<button
class="inline-link-btn"
type="button"
onclick={() => (activeTab = 'cli')}
>CLI tab</button>
for terminal access.
<strong>No claim code needed on this deployment.</strong>
Agents connected via the CLI or stdio MCP use your user
session and already have access to every workspace
youre a member of.
</p>
</div>
{:else if claimState.kind === 'error'}
@@ -627,8 +630,20 @@
>
Troubleshooting
</a>
<span class="footer-sep">&middot;</span>
<a href={CONNECTED_APPS_HREF}>Connected agents &rarr;</a>
<!--
Hide the Connected apps link on self-host deployments
without remote MCP (mcpPublicUrl empty). That page
lists OAuth grants only, and self-host without
`PAD_MCP_PUBLIC_URL` never mounts the OAuth server —
so the page would be empty by definition. Linking
users there is a dead end; matches the
"claim_disabled" copy that tells the same audience
they're already done.
-->
{#if mcpPublicUrl}
<span class="footer-sep">&middot;</span>
<a href={CONNECTED_APPS_HREF}>Connected agents &rarr;</a>
{/if}
</div>
</div>
</div>