MCP

Confluye speaks the Model Context Protocol (MCP) in both directions:

• Confluye as a server: Claude Code and ChatGPT can inspect your Confluye workspace without exporting data or copying it into a prompt.
• Confluye as a client: workflows and AI agents can call tools from an external MCP server.

For a read-only session the external Confluye server exposes stable operations for workspaces, capabilities, workflows, runs, documents, knowledge bases, and tables. It also exposes non-mutating workflow planning tools: workflows.propose, catalog.search, catalog.get, workflows.validate, workflows.diff, and the documents.status lifecycle read — and publishes no mutations. A session that holds the mcp:write scope — for example a workspace API key — additionally gets typed workflow publication, debugging, document lifecycle, connection administration, and selected platform capability tools. They reuse the same registry schemas, role checks, confirmation, and idempotency rules as every other Confluye surface. Read-only clients never see or invoke those write tools, and a write tool additionally requires the signed-in user to hold a Member, Admin, or Owner role in the workspace — a Viewer is refused. Governed workflows.deploy is narrower: it is available only through a workspace API key with AIMS service_token assurance, and the key's acting user needs a current AIMS aims_manager or system_owner service-token assignment. OAuth and browser MFA do not grant MCP deployment authority.

Personal website sessions are available through browser.list and browser.read. Complete login in Manage my browser connections and enable Allow my agent to read, then ask your MCP client to list your connections and read a page with the selected connection. A page read requires workspace execution access even with mcp:read. The tools use only your own saved login and return page text and links; interactive login and changing the permission remain in the connection screen. See Personal website sessions.

Apps

Workspace and organization connections expose apps.list, apps.get, apps.backends, apps.invocations and apps.run for reading Apps, supported workflow destinations, the caller's own request history and a selected invocation result. apps.invocations and apps.run require workspace secret-read or write authority; read-only organization grants do not expose them, even for an Owner. Write-capable sessions also expose apps.create, apps.save, apps.publish, apps.invoke, apps.externalAccess and apps.configureExternalAccess. Reading the share link requires workspace write authority because the link is an access credential. Enabling external access additionally requires execution authority; changing to internal mode can revoke the grant without it. These use the same canonical schemas, current workspace permissions, confirmation, idempotency and audit as the visual App editor and viewer. Processing additionally requires execution authority.

An App is a persistent typed form over an exact published workflow destination. The server reads its workflow, destination, version and activation from the published snapshot, then executes as the current authenticated caller. A stopped or changed backend is refused rather than replaced silently. The result belongs to the selected invocation, not the latest run of a workflow.

External visitors use a separate App-session MCP endpoint at /api/apps/<share-token>/mcp. It exposes only app-visitor.get, app-visitor.invoke, app-visitor.run and app-visitor.invocations, with a bearer issued for that App and visitor session. Workspace and organization credentials do not supply that identity. Shared access does not confer customer Product gateway authority or customer consent.

Select workspaceId explicitly on the organization endpoint; a workspace endpoint supplies its workspace from the URL. See Apps and the MCP request reference.

Customer calendars and saved website sessions

Configure a separate Product MCP connection at https://confluye.run/api/v1/end-users/mcp with Authorization: Bearer <product-gateway-key>. Use a Product gateway key with Run permission and the exact workflows your product may execute. This connection serves your customers; the workspace and organization connections above continue to serve Confluye members.

The product connection can create, update and remove product-owned calendar events, execute published workflows for a customer, follow or cancel its runs, request a customer website login link, inspect saved-login status and retrieve private routine artifacts. Calendar writes still require the customer's calendar_write consent. Website routines still require the workflow's reviewed site grant and the customer's own saved session. MCP cannot sign in or approve those grants on the customer's behalf.

See Product MCP for tools and examples. Workspace, organization and personal keys cannot authenticate to this endpoint. Product keys do not authenticate to the administrative MCP endpoints. The deployment's MCP server stop also stops Product MCP.

Organization invitations and Checkout

Write-capable workspace and organization connections expose organization-invitations.list, organization-invitations.cancel and billing.checkout. They require current organization Owner/Admin membership; a workspace Owner alone is insufficient.

1. Call the tool with its arguments, confirm: true and an idempotencyKey.
2. Open the returned approvalUrl in your browser. Sign in as the same Confluye user and verify MFA.
3. Review the organization, workspace and exact invitation or plan, then approve.
4. Repeat the tool with the original arguments and key, adding its authorizationRequest.

Opening the page does not approve anything. Changes to the reviewed invitation or price invalidate the approval. Approval lasts at most five minutes and never extends the remaining MFA verification window. Repeating a completed request retrieves its receipt subject to current membership. Each new invitation-list page needs a new request and approval; its completed receipt is a snapshot, not a live directory. Checkout returns the payment page; completing payment remains on Stripe.

Google Workspace MCP

In Settings → MCP Servers → Google Workspace MCP, select Gmail, Drive, Docs, Sheets, Slides or Calendar and choose Read only or Read and write. Use Connect Google service, complete any required account verification, then consent in Google. The callback tests and discovers the connection before making its tools available. Each service has its own connection and permission profile. Changing workspace or leaving this panel cancels a pending connection request; connect again from the workspace you intend to use.

The deployment administrator must provide a separate Google OAuth client for agents, confirm its AI-agent classification, register its Client ID under the production OAuth release policy, enable the selected Google MCP services and configure content screening. Google's Developer Preview and Workspace administrator policies also apply. A missing client or screening configuration leaves the Connect action unavailable; an unregistered classification or denied consent is explained after the attempted connection.

Live Google MCP connections require the deployment's persistent database, including in local development. A private deployment signing key is also required in every environment. The administrator must configure it before connecting a real Google account; public development defaults cannot sign or validate Google grants. Connections stored only in an in-memory demo or test fixture cannot authenticate to Google; the administrator must restore database-backed operation before connecting a real account.

Google agent credentials are personal by default. Connecting MCP preserves Google login and existing REST integration grants. Sharing a workspace credential requires an explicit separate action, and does not grant additional Confluye permissions. Read-only connections enable only tools identified as read-only; writing or unclassified tools require a different permission profile and another consent.

A personal Google connection is configured only for its credential owner. Other workspace members and unattended runs need their own consent or an explicitly shared workspace credential. Use the Google setup panel and the canonical service endpoint; generic MCP connections and alternate URL forms cannot bypass Google authorization.

Imported Google tokens must be verified with Google before use. Changing a client ID in the credential JSON cannot change the token's actual issuer. If verification identifies a traditional client, reconnect through the separate agent client; if Google verification is temporarily unavailable, retry later. Native consent records signed issuance metadata. Imported grants must also use an agent client distinct from Google login and traditional clients configured by the deployment or selected workspace.

An imported token without saved scope metadata is verified with Google before the selected service's permissions are checked. If a renewal omits permissions, Confluye verifies the renewed token with Google even when the previous access token has signed issuance metadata. The signed proof binds the access token, refresh token, client and permissions from native Google consent. An imported credential containing a refresh token, a replaced refresh token, or an older proof cannot establish account continuity: use Connect Google service again before testing or running tools. Imported access tokens without a refresh token remain available after Google issuer and permission verification. Production approval covers all verified permissions held by the token, including permissions beyond the selected MCP profile. Starting another connection action replaces feedback from an earlier failed action.

Use Test connection to refresh discovery, Reconnect for expired or insufficient grants, and Disconnect to remove the connection's credential binding. Disconnect does not revoke Google's grant for other consumers. A changed account, connection or tool snapshot requires reviewing the action again. Manually replacing a bound credential also invalidates pending actions and existing transports, even when its credential ID stays the same. Use Test connection to discover the replacement account before reviewing the action again, including when the credential ID stays the same. Normal token renewal preserves discovery readiness and the connection revision. Sensitive agent actions retain their existing confirmation rules.

Changing the bound account or permission profile makes tools unavailable immediately. Use Test connection to discover tools again before running them. Reconnect temporarily makes tools unavailable until discovery succeeds, then restores your selections for eligible tools. Tools you disabled remain disabled. Switching to read-only makes writing and unclassified tools unavailable without erasing their saved selections. Switching back to write access and refreshing restores eligible selections. Tools missing from the current discovery remain unavailable until the server offers them again. Read-only calls are also checked at execution, including direct SDK calls. Disconnect is available before the first grant is installed, so you can cancel pending consent. Disconnect or another connection change invalidates pending Google consent: start a fresh connection request instead of completing the older window. Connection access is checked when a credential is attached and before MCP calls, including for imported credentials. Registered clients allow authorized users by default; an explicitly verification-only client also requires approved scopes or an exact verification audience. This setting does not certify Google approval.

An existing approved write grant can serve a read-only connection for the same service without another consent. Confluye still blocks writing tools for that connection. Selecting read-only does not remove permissions from Google's retained token; production approval must cover that token's complete grant.

If Google says the client is not marked as an AI agent, ask the Google Cloud administrator to classify or replace the client; repeated login cannot resolve that error. For a scope error, reconnect with the required service permissions. For a policy denial, contact the Workspace administrator. Google Drive MCP can filter ineligible files that remain visible in Drive; Confluye does not bypass this restriction through REST.

See Google's client classification guide and Workspace MCP setup. Deployment and actual Google access still require administrator configuration and live verification; local fixtures do not certify a Google project.

Why connect an AI client to Confluye?

Once connected, you can ask an AI client to answer questions such as:

• Which workflows are deployed, and what do they contain?
• Which runs failed recently, and what did their logs report?
• What does our indexed workspace knowledge say about a topic?
• Which documents and tables are available for analysis?
• Is a capability ready, or does it still require setup?

The client receives live, workspace-scoped results. Confluye checks the workspace on every request, redacts secret-shaped output, rate-limits clients, and audits tool calls without storing bearer tokens.

Native services during a migration

Workspace and organization MCP connections give AI clients guidance to suggest Confluye's built-in services when relevant to your request:

• Structured data: inspect existing databases and tables and consider native database workflow blocks when migrating records or replacing an external database.
• RAG and document retrieval: use the internal Knowledge service for indexing and retrieval, with knowledge.list, knowledge.get, knowledge.search and the available document lifecycle tools.
• Assets and images: use Workspace Files, keeping file IDs and metadata in database records. Production bytes stay in private object storage. Upload through the app or the authenticated Files HTTP API; MCP has no file upload tool. Ready images can be linked to table records with tables.imageTarget and tables.setImage when those tools are available.

This guidance is supplied through initialization instructions and the capabilities.list tool description. Your AI client decides how to use it. It should explain relevant options in your language and respect your choice of external services. Recommendations do not migrate data automatically or grant permission to write. The current tools/list, connection permissions and service readiness determine which actions are available. Organization clients select a permitted workspace with workspaces.list and supply its workspaceId on workspace-bound calls.

Connect from workspace settings

The shortest path starts in Settings → API Keys → Connect MCP. Confluye already knows the active workspace, so the dialog generates its exact endpoint automatically. Choose the reach first:

• This workspace: tools act only in the current workspace. The dialog checks the workspace resource status before showing the endpoint: while that check runs it shows "Checking workspace MCP availability…"; if the check fails, "Workspace MCP availability could not be loaded." with a Retry action. When the endpoint is not yet set up, a workspace Owner or Admin sees Set up workspace MCP — MFA-protected, limited to the standard MCP scopes, and audited; other roles see the same explanation with Use a workspace API key instead, and both link to the Operator troubleshooting guide. A disabled or incompatible endpoint always shows the operator-review message with no setup commands. An active read-only endpoint (an operator-provisioned row that allows mcp:read but not mcp:write) shows a Read-only badge, and its Codex login command requests only mcp:read,offline_access.
• Whole organization: one connection (confluye-org) for the organization. When you authorize the client, the consent page asks which workspaces it may reach (all, or a selection) and whether it may write. Each tool call then names its workspaceId; workspaces.list shows the workspaces the grant covers. When the organization endpoint is not yet provisioned, the organization Owner who is also an explicit workspace Owner or Admin sees the same kind of self-service setup; other roles get the operator-review guidance. Review and revoke authorized clients under Authorized MCP clients in the same section.

Choose a client:

• Cursor: click Add to Cursor, approve the server, and complete the Confluye OAuth login.
• Claude Code: copy the generated command, run it, then open /mcp and complete OAuth.
• Codex: copy and run the two generated commands, then complete the browser login.
• ChatGPT: copy the endpoint into a custom app in developer mode, select OAuth, and scan tools.

OAuth is the default because it avoids manually distributing API keys. DCR registers supported public clients automatically, while PKCE binds the authorization code to the client that started the login. Confluye validates that the requested endpoint belongs to its public origin, names an existing workspace or organization, and is an approved, enabled resource before showing consent.

Connect Claude Code with an API key

Use this fallback for non-interactive environments or when OAuth has not been enabled for the workspace. It uses a workspace API key in an environment variable; the key is not written into a versioned .mcp.json.

1. 1

   Create and copy a workspace API key

   Open Settings → API Keys, click Create, keep the scope set to Workspace, and create the key. Use the Copy button immediately: Confluye shows the full token only once.

2. 2

   Export the token and find the workspace ID

   Export the copied token in the shell that will launch Claude Code. Then query the workspace endpoint; the UI slug, such as default, is not the workspace ID.

   export FLUXUS_HOST="https://confluye.run"
   export FLUXUS_MCP_API_KEY="<token-shown-once>"
   
   curl --fail --silent --show-error \
     --header "Authorization: Bearer ${FLUXUS_MCP_API_KEY}" \
     "${FLUXUS_HOST}/api/v1/workspaces"
   

   Copy the workspace.id value from the JSON response, then export it:

   export FLUXUS_WORKSPACE_ID="workspace-id-from-the-response"
   

3. 3

   Add the Streamable HTTP server

   Run this command from the project where you use Claude Code. All Claude options must appear before the server name.

   claude mcp add \
     --transport http \
     --scope local \
     --header 'Authorization: Bearer ${FLUXUS_MCP_API_KEY}' \
     confluye \
     "${FLUXUS_HOST}/api/v1/platform/mcp/${FLUXUS_WORKSPACE_ID}"
   

   Local scope stores the server in your private Claude configuration. The single quotes preserve the environment-variable reference instead of placing the token value in the command-generated configuration.

4. 4

   Verify the connection and call a real tool

   Start Claude Code from the same shell, run /mcp, and confirm that confluye is connected and exposing the Confluye tools. A workspace API key carries the mcp:write scope, so the list includes the typed workflow publication tools alongside the read tools. You can also inspect the configuration before starting a session:

   claude mcp get confluye
   

   Then ask Claude:

   Use Confluye capabilities.list and summarize which capabilities need setup.
   

To disconnect, run claude mcp remove confluye and revoke the key from Settings → API Keys.

Connect ChatGPT to Confluye

ChatGPT uses Confluye OAuth instead of a manually copied API key. You need a ChatGPT workspace and role that can create custom MCP apps in developer mode.

1. 1

   Create a custom app

   Enable developer mode in ChatGPT, open Settings → Apps → Create, and enter the exact Confluye MCP endpoint:

   https://confluye.run/api/v1/platform/mcp/your-workspace-id
   

2. 2

   Authorize Confluye

   Select OAuth authentication. ChatGPT discovers Confluye authorization metadata automatically. Sign in to Confluye, review the requested mcp:read permission, and click Allow read access.

3. 3

   Scan and verify tools

   Click Scan Tools. A read-only OAuth grant finds the Confluye read tools (capabilities, workflows, runs, documents, knowledge bases, and tables) and no workflow write tools. Create the app, enable it for your account, and ask the same verification question used with Claude Code:

   Use Confluye capabilities.list and summarize which capabilities need setup.
   

ChatGPT OAuth uses Authorization Code with PKCE S256, dynamic client registration, explicit consent, refresh-token rotation, and revocation. The token must belong to an active Confluye user who is a member of the workspace in the endpoint URL.

Confluye platform tools

The server advertises these stable read operations to every authorized session:

Managed configuration uses the same workspace and role checks as the Tables panel. Its read tools are configuration.catalog, configuration.readRows, configuration.export, configuration.validate, configuration.preview, and configuration.history. The catalog reports database and table metadata; for an undeclared table it exposes its name and metadata only, never rows. Managed row values are returned only for explicitly declared tables, and exports are limited to selected declared tables.

A successful configuration catalog includes applyEnabled and applyDisabledReason (null or writes_disabled). These report deployment availability; they do not grant write permissions.

Write-capable sessions may also see configuration.prepare, configuration.apply, configuration.declare, and configuration.writeRow. prepare creates a proposal and returns a link to the authenticated Tables panel. MCP has no configuration.confirm tool: the human session in that panel issues the confirmation, while apply consumes the resulting confirmation and remains subject to the same workspace, Admin/Owner, drift, non-sensitive, and durable-storage checks. These tools do not expose SQL overrides or delete operations, and an agent cannot auto-approve a package. The apply, declare, and writeRow calls require both confirm: true and an idempotencyKey; the key identifies a retry and does not replace confirmation. After a lost apply response, retain the original request identity and arguments. An authorized retry can recover its committed result even if new applications have since been disabled. Exact retries of completed declarations and row writes can likewise return their stored result while new writes are disabled, subject to current authority and retained idempotency records. History receipts report the applied status.

The server implements initialize, tools/list, and tools/call over Streamable HTTP using MCP protocol version 2025-06-18.

Read-only authoring tools let a client search the validated block catalog and review a candidate before any mutation. workflows.prepare-test-data accepts executionTargetId to keep fixtures in the selected preview; omitted destinations use Production. workflows.prepare-test-data, workflows.test, and workflows.execute-step appear only to write-capable sessions. Test runs simulate external writes by default; live step execution requires an explicit workflow version. See the Platform MCP reference for the complete runtime-derived inventory and rollout controls.

File entries use workflows.file-test-start, workflows.file-test-status and workflows.file-test-cancel for temporary candidate listeners. They enforce current execution permission and listener ownership. MCP receives listener metadata, not private upload URLs or tokens. Use the editor or authenticated HTTP API to obtain the upload URL. File bytes stay in HTTP uploads; workflows.execute accepts ready Workspace File IDs through input.fileInputs. Organization MCP calls must explicitly select a workspace the principal may execute in.

A session holding mcp:write also sees workflow publication tools, governed capability waves, and the Knowledge Document lifecycle. workflows.deploy appears only for an AIMS-authorized workspace API key; OAuth sessions do not discover it. Mutations take confirm: true and an idempotencyKey when their registry policy requires them, and are refused for a Viewer:

Integrations can be set up the same way. catalog.search finds a provider's blocks and credential type, credentials.create stores its secret through a workspace API key, credentials.test runs the Settings connection test, and workflows.update-target with configure-source connects a Jenkins or RSS event source to a destination. workflows.targets then reports each source's polling state. See the Platform MCP reference for their authorization rules.

When the deployment enables end users (FLUXUS_END_USERS=true), sessions with explicit workspace access also see the owner's end user tools. end_users.list, end_users.get, memory_resources.list, site_notes.list, and site_notes.get are reads; end_users.update_fact, end_users.delete_fact, end_users.erase, memory_resources.create, memory_resources.connect, memory_resources.disconnect, and memory_resources.delete require mcp:write. Reading or changing a customer's conversation, facts, or notes requires explicit workspace Admin or Owner membership, and so does memory_resources.delete, because it deletes every customer's memory in the resource. Every content read is audited. Approving a site note and creating a product gateway key are not available through MCP.

For an existing workflow, workflows.propose automatically pins the current version when expectedVersion is omitted. Send the same workflow intent to workflows.apply, either omitting the version again or passing the exact expectedVersion returned by the proposal, together with the returned planHash, confirm: true, and a stable idempotencyKey. If the workflow changes between review and apply, request a fresh proposal after the -32009 / workflow_proposal_stale response. Retrying an already successful apply with the same key and arguments replays the first result instead of creating another version.

Before MCP can deploy, a human completes the controlled AIMS workflow in Settings → AI Governance: assessment, independent approval, a dated renewal or explicit No scheduled renewal, and activation of the approved system version. An AIMS-authorized service-token key can read bounded status through aims.governance.get; the response includes a UI handoff URL but no evidence, rationale, approvals, manifests, or hashes. MCP intentionally exposes no aims.* mutations for the human-controlled steps. After activation, call the typed workflows.deploy tool with the reviewed workflow version. command.submit is an authoring and scheduling entry point, not an alternative path for governed deployment.

Configure a Confluye deployment for OAuth clients

OAuth clients require the deployment operator to set the public Confluye origin:

BETTER_AUTH_URL=https://confluye.run

Confluye accepts an exact MCP endpoint only when it uses that origin and its workspace ID exists in PostgreSQL. Token issuance additionally requires the signed-in user to remain an active workspace member. New workspaces do not require deployment-variable changes: a workspace Owner or Admin self-provisions the workspace endpoint from Connect MCP, and an organization Owner who is also an explicit workspace Owner or Admin self-provisions the organization endpoint the same way. The operator CLI below remains for disabling a resource, changing its scope policy, and non-interactive or bulk provisioning. No ChatGPT client ID or client secret is required because Confluye supports public dynamic client registration.

When self-service is not available or an operator needs to provision outside the UI, preview the change first, issue the exact capability confirmation shown by the preview, and only then apply it:

AIMS_OPERATOR_CHANGE_TICKET=CHG-124 BETTER_AUTH_URL=https://confluye.example \
  pnpm aims:operator mcp-oauth-org-resource-provision \
  --organization-id ORGANIZATION_ID \
  --workspace-id ANCHOR_WORKSPACE_ID \
  --actor-id OPERATOR_USER_ID \
  --assurance service_token \
  --allowed-scopes mcp:read,mcp:write,offline_access

The preview returns the confirmation request and plan hash. Disabled resources and existing resources with different scopes stay blocked for operator review; the settings dialog never reactivates or rewrites them.

Troubleshooting external clients

Confluye binds each authorization code and rotated refresh-token family to the workspace resource approved on the consent screen. A client cannot reuse that grant to mint a token for another workspace, even when the same user belongs to both workspaces. At the MCP endpoint, invalid OAuth claims such as the wrong audience or a missing mcp:read scope return 401; 403 is reserved for a valid credential whose user or API key cannot access the workspace in the URL.

Connect an external MCP server to a workflow

Register an external server in Settings → MCP Tools. Each connection stores an http or sse transport, endpoint URL, optional authentication headers, enabled state, and discovered tools. Streamable HTTP is preferred; SSE is supported for compatibility.

Enter the server's final endpoint URL. MCP requests refuse redirects to a different scheme, host or port before sending the next request. Redirects within the same origin remain supported. If a connection reports egress_blocked after a redirect, update its endpoint to the provider's final URL and test the connection again.

A server registered as a product connection cannot be deleted directly. A workspace Admin or Owner must remove that product connection first, preserving unwithdrawn mailbox grants for the existing bounded cleanup retry. The server can then be deleted; a premature delete returns 409 mcp_product_connection_attached.

You can use a connected tool in two ways:

1. Add it to an AI agent block so the agent can call it while reasoning.
2. Add an MCP Tool node to call a specific tool directly as a workflow step.

Use Test connection to refresh the server's tool definitions. AI agent blocks use the discovered parameter schema to prepare their calls and send the selected arguments without adding workflow context fields. If a server changes its required parameters, refresh the connection before running the agent again. Existing permission and confirmation requirements still apply.

With Agent Runtime v2, a tool name or parameter definition containing a saved credential value stops the agent before the model call. Remove that value from the server's tool definition and refresh the connection.

Test an individual tool from the MCP server settings before wiring it into a workflow. The client call timeout is controlled by WORKFLOW_MCP_TIMEOUT_MS and defaults to 10 seconds.

Your own product as an MCP server

When the MCP server is your own product, a workspace Admin can register it as a product connection. Every request Confluye then sends to it carries a signed run context: the run, workflow, version and end user it belongs to, and the productContext your product sent when it started the run. The context travels in request headers your server verifies with its signing secret; agents and tool arguments never see it. A product connection can also bind allowlisted context fields, such as the delegation reference, to extra request headers. It must use HTTPS and a public host, checked when it is registered and again on every request. Servers that are not product connections are unchanged.

Let your product decide the confirmations

By default, when an AI agent block calls a tool on an MCP server, Confluye pauses the call for an approval, and the people who work in the workspace answer it. That is the wrong person when your product serves its own customers: your product already knows who may do what and asks its own user to confirm.

A workspace Admin can mark an MCP product connection as trusted for a list of workflows. In those workflows, an agent block's calls to that server run without a Confluye approval. This is what changes, and what does not:

• The product decides. When your product answers a call with pending_confirmation, the agent receives it as the result of the tool, like any other result. Confluye opens no approval for it.
• Only the listed workflows. In any other workflow the connection asks for an approval per call, as before.
• Everything else still applies. The block's allowed-tool list and budgets, the check that stops a call that tries to send a secret, and the permissions of the member the workflow runs as. A trusted tool that is not on the block's allowed list is refused.
• Only the custom guardrail profile. It is the block's Policy profile, in its Guardrail policy. A block set to reviewed-mutations or read-only keeps asking. custom is also what a block uses when no profile was chosen, so a block you have not changed already qualifies.
• It ends when the connection changes. Editing the server's URL, headers or transport removes the trust and records the loss in the audit log. An Admin has to approve again, even if the edit is undone. Changing only the server's tool list or enabled switch, or rotating its signing secret, does not remove it.
• Only MCP servers. A product connection to an HTTPS base URL cannot be trusted; its tools keep asking.

Granting, changing and revoking the trust are Admin actions that need a recent step-up and are audited. See Trusted connections. For ordinary Agent V2 MCP calls, Confluye reads the trust again before each tool call, so granting, changing or revoking it applies to the next call of new, running and resumed runs alike. After you revoke it, an Agent V2 run that is already running asks for an approval on its next call to that server; you do not need to cancel the run. A call that has already started is not interrupted.

Codex CLI and Claude Code nodes use the same trust and signed run context through a temporary product connection door. The CLI sees one loopback MCP server with only the selected product tools. Its bearer is supplied through the CLI's MCP attachment configuration. The CLI never receives the run identity, productContext, signing secret or signed request headers. Confluye adds signed headers to requests sent directly to your product. The door checks current workflow trust and connection configuration before listing or calling tools, and checks tool arguments for secrets before forwarding. Codex CLI and Claude Code door calls are refused, with no approval opened, when trust is absent or revoked. This also applies to the next call from an already-running or resumed node.

A CLI node that selects product connection tools can also use only the saved-browser session attached to that run. It cannot combine those product tools with another MCP server. Its instruction skills remain available. An untrusted product connection is refused when the workflow is validated, published or admitted for a run. Existing workflows with a product connection and another MCP server, or without workflow trust, must be corrected before they can run; revoking trust after admission makes subsequent CLI door calls refuse without opening an approval.

The door returns rejected calls as MCP tool errors with stable codes. A successful CLI exit code does not prove that a product action happened; check the tool result and the run's Logs, where each refusal is recorded with its code. A resumed node execution opens a new door with the run's saved context and original delegation reference. The CRM owns delegation renewal; Confluye does not add a renewal channel.

Find the product tools a node selected

When a product exposes many operations, a Codex CLI or Claude Code node does not need all of them in its prompt. Besides the selected tools, which stay available as product_tool_1, product_tool_2 and so on exactly as before, the door lists two read-only helpers for that node:

• product_tool_search takes a query (up to 200 characters and 8 words) and an optional limit (1–25, default 10). It returns the selected tools whose name, title or description contain every word: the door alias, the product's own operation name, a clipped title and description and any hints about effects. It returns no schemas.
• product_tool_describe takes one alias such as product_tool_1 and returns that tool's current title, description, input schema, output schema and annotations. It accepts an alias only, never an operation name.

They are a way to find and read about tools, not a way to use them:

• Selected tools only. They cover the tools you selected on that node and only while the connection is trusted for the workflow and its configuration is unchanged. A tool that was not selected, that the product no longer offers, or whose connection lost trust never appears, and a failure returns only a stable code, never text from your product.
• Nothing runs and nothing is granted. Finding or describing a tool does not call it, add a tool, widen the workflow's trust or give the node a permission. Calling still goes through the direct alias with the same trust check, secret scan and signed identity, and there is no tool to run arbitrary operations or code through the door.
• Fresh schemas. Each call reads the product's current tool list through the same signed request path as listing, so a schema your product changed is returned as changed.

A tool's schema describes the operation in general. It cannot say which records, options or fields the signed-in person is allowed to use, or which fields are required for one customer right now. When that depends on your product's authorization, publish it as an operation of your own product, for example one that returns the fields of a record type for the person in the signed run context, and let the node call it through its direct alias. Treat only what such an operation returns as the current fields for that person; the generic inputSchema from product_tool_describe is not that answer. The refusal codes of the helpers are in the product connections reference.

What a node remembers about each customer it works with is separate from the tools it can use: see Remember customers separately.

Use a saved website login with Codex or Claude Code

In a Codex CLI or Claude Code node, open Playwright MCP · saved browser and select your personal browser connection. Save the node, click Authorize browser control, then save again. Confluye attaches Playwright through the node's existing MCP mechanism. Instruction skills remain available. Other selected MCP tools remain available unless the node also selects product connection tools; in that case only the product connection door and this run's saved-browser session can be attached. You do not need to register a separate MCP server or create a skill for each website. Once browser control is authorized, these browser tools can run unattended. This grant does not authorize tools on other MCP servers, and revoking it stops subsequent browser calls.

The agent can navigate, read a page snapshot, click, type, fill forms, select options, press keys, hover and wait. Clicking or submitting a form can change the connected account, so this permission is separate from conversational read access and existing read-only browser blocks. Cookies remain on the browser worker. Access is limited to this owner, workspace, workflow and node, and the site's allowed domains. Each run gets its own temporary browser from the saved login, which Confluye saves and closes afterwards. Other runs and agent reads can use the same connection at the same time, so avoid simultaneous changes to the same account. Revoke block access stops subsequent tool calls.

Connect and verify the website first in My browser connections. A saved login is a reusable session, not automatic sign-in: Confluye does not sign in for you, so an expired website session needs login again. Customers of a product you build sign in to their own sites through a login link instead; see Website logins for end users. Code execution, cookie inspection, uploads and downloads are not exposed by this attachment. Support depends on the site's authentication and browser compatibility.

Next steps