[bug] An unconfigured connector renders a red error on every agent's Settings tab — Zoho WorkDrive has never been configured

[serge-ivo]

What every user sees, on every agent

Production, checked just now:

GET /v1/workdrive/status  →  { "connected": false, "configured": false }

configured is !!(ZOHO_CLIENT_ID && ZOHO_CLIENT_SECRET) (routes/workdrive.ts:79), and both are
commented out in workers/api/wrangler.toml:51,140. Zoho WorkDrive has never been configured on this
deployment.

The console renders that as an error, in red, on the Settings tab of every instance
(SettingsTab.tsx:927):

⚠ Zoho WorkDrive connection isn't configured on this deployment yet.

and then, immediately below (:1014-1032), a dead row:

Zoho WorkDrive · not connected

with no button — because the Connect button is gated on configured (:1021) while the row around it
is not.

Why this is worth a ticket

The red is the problem, not the row. Red is the console's colour for something went wrong that you
should deal with. This is a deployment gap — no OAuth client exists — so there is no action the
subscriber can take, and no amount of clicking will change it. We are showing a user an operator's
unfinished work, styled as their error, on 26 instances, forever.

Google Drive is configured: true, so it escapes the red — but it renders the same dead
"not connected" row plus a folder-grant box on every agent, including ones with no file tools at all.
That half is #352's to fix properly.

The rule

A connector that cannot be connected should not be on the page. configured: false is
information for whoever runs the deployment, not for the person using it. If we want it visible at
all, it belongs in the admin portal next to the other deployment state.

Concretely, in SettingsTab.tsx:

• Drop the three !configured red lines (:921, :924, :927).
• Gate the whole Gmail / Drive / WorkDrive block on status?.configured, not just its button — so an
  unconfigured connector contributes nothing, rather than a labelled row that does nothing.

That is the five-line version and it should land on its own. #352 then deletes these blocks
entirely by deriving them from the agent's declared tools.

Note for whoever picks this up

The same configured flag is already modelled honestly elsewhere — the MCP connector_status tool
documents configured:false as "the deployment has no OAuth client for it — no amount of clicking
will connect it." The console is the surface that didn't get the message.

[serge-ivo]

Second site, and it is the worse one

The body flagged that TriggersSection receives driveGrants/workdriveGrants as props and asked
whether hiding the Settings block leaves it inert. Traced it — it does not, and the trigger UI has
the same defect in a form that outlives the page.

TriggersSection.tsx:417-433, the sync_connector action:

<select value={provider} onChange={…}>
  <option value="google_drive">Google Drive</option>
  <option value="zoho_workdrive">Zoho WorkDrive</option>
</select>

Both options are hardcoded and gated on nothing — not configured, not connected. The folder-grant
picker below it degrades to a single disabled-looking option (:429) reading "No granted folders",
which is the same sentence you would get for a connector that IS configured and simply has no grants
yet. The two situations are indistinguishable, and only one of them is fixable by the user.

Why this is worse than the red line

The red line in Settings is noise. This one persists. A user can select Zoho WorkDrive, pick a
schedule, and save a cron trigger on a deployment that has no Zoho OAuth client at all. What they get
is a scheduled job that will never sync anything, sitting in the trigger list looking healthy — the
failure mode #182's delivery work exists to eliminate, reintroduced one layer up at configuration
time.

The grant picker's empty state should also distinguish the three cases it currently collapses into
one: not configured on this deployment · configured but you have not connected it · connected but
no folders granted. Only the third is a prompt to act.

Adds to the fix

• Build the provider <option> list from connectors that are actually configured, rather than
  hardcoding two.
• If none are, hide the sync_connector action from the action picker entirely — an action with no
  possible target is not an action.
• Give the empty grant state the reason, not just the absence.

This is still a small, self-contained frontend change and still lands independently of #352.

Sequence for the set: this → #354 → #355 → #352.

[serge-ivo]

Sibling in the same component: #358

#358 covers the other ungated axis of this same picker. Splitting them by axis rather than merging:

• this issue gates the sync_connector connector options on deployment configuration (configured)
• [bug] A scheduled browser run can be saved on 25 of 26 agents that cannot perform one — and on cloud-only agents it skips forever telling you to run pags up #358 gates the action options on agent capability (run_browse needs workflow:"BROWSER_TASK")

The shared conclusion is that TriggersSection's whole vocabulary — seven actions and two connectors — is hardcoded and gated on nothing, so whoever picks up either should do both.

One note carried over from #358 that applies here too: the gate belongs server-side, in trigger validation. The console, the API and the MCP tool create_instance_trigger are three equal doors onto the same table; a TriggersSection-only fix closes one of three.

Minor, related, not worth its own issue

lib/connections.ts:213 — when a run_pipeline connection names a pipeline that does not exist on the target instance, loadPipeline returns null and unattendedWarningsFor returns []. The case most deserving a warning is the one case that produces none, and the connection is created looking clean. Blast radius is small — the outbox dead-letters it after 5 attempts (#182 working as designed) — so this is a one-line improvement to fold in if someone is already in this file, not a reason to open anything.

[serge-ivo]

Landed in 8ab3481.

Claims checked, all held. GET /v1/workdrive/status → {connected:false, configured:false} (both Zoho vars are still commented out in wrangler.toml), and SettingsTab rendered three text-red "isn't configured on this deployment yet" lines plus a labelled row whose Connect button was gated on configured while the row around it was not.

What an unconfigured connector renders now: nothing. lib/connectorState.ts resolves the two flags into a named state — unknown | unavailable | disconnected | connected — and showsConnector answers the only question the page has: does this belong in front of this user. Same distinction #263 draws between unsupported (a correct answer) and unreadable (we could not ask), and the one #348 drew between unmetered and $0.

unknown is deliberately hidden too. Rendering the row before the answer arrives makes a connected account flash through "not connected", which reads as a disconnection.

Gated on it: the Gmail / Drive / WorkDrive rows and their folder-grant boxes, the "read my inbox" permission checkbox (it pointed at a "Connect Gmail above" row that is now gone), and — one the ticket doesn't mention — Knowledge's + Drive / + WorkDrive import buttons. Those panels' only advice is "connect it in Settings", where the connector is now correctly absent, so hiding the Settings row alone would have converted one dead end into a worse one.

The red lines are deleted rather than recoloured. configured:false is information for whoever runs the deployment; the MCP connector_status tool already documents it honestly, and that is where it belongs.

Rules are pure and tested (connectorState.test.ts, 7 cases including connected:true, configured:false → unavailable). #352 still owns deleting these blocks entirely by deriving them from the agent's declared tools.

CI green.