Troubleshooting

Agent Can Read the Web But Can’t Click Buttons?

That’s usually expected. Here’s how to separate normal “read-only web access” from true automation, and what to do next.

A recurring support complaint is: “It found the page, but it won’t click Sign In / Submit / Publish.” In most setups, your agent can fetch and summarize web content, but cannot control live browser UI flows unless a specific automation tool is configured.

Mental model: reading a webpage and operating a webpage are different capabilities. If no browser-control tool is installed, click/submit actions will fail by design.

What “works” vs what “doesn’t”

Usually works: opening public URLs, extracting text, summarizing pages, comparing docs.
Usually does not work: logging in, clicking buttons, filling forms, navigating CAPTCHA, publishing posts.
Sometimes works: API-based actions (if a connector/tool exists and is authenticated).

Fast diagnosis in 90 seconds

Ask your agent: "What tools are available in this session?"
If you only see web fetch/search style tools, assume read-only behavior.
If you expect click automation, verify that a browser automation connector is actually installed and authorized.
Retest with a simple, non-auth page before trying login-protected workflows.

High-friction edge case: “I installed Chromium but it still can’t click”

This is showing up often in community chats. Installing a browser binary by itself does not automatically give your agent browser-control capability.

Browser installed ≠ automation enabled: Chromium can exist on the host and your session can still be read-only.
Session mismatch: you may have enabled tooling in one environment but are testing in another (DM vs server, old thread vs new thread, different workspace).
Wrong success test: “it can open a URL” is not proof it can click/login/submit.

Loop-break rule: Stop retrying broad “use Chromium and post this” prompts until you pass a tiny canary test that proves click capability in your current session.

2-minute canary test (proof before production)

Before doing the full workflow, run this exact test: 1) Tell me clearly whether you can perform browser UI actions in THIS session (yes/no). 2) If yes, name the exact browser automation tool available. 3) Run one tiny canary task that requires a click on a safe test page and report evidence. 4) If no, switch to manual-handoff mode and give step-by-step click instructions for me. Do not claim completion without evidence.

Advanced edge cases (when basic checks still fail)

Popup/consent walls: cookie banners, region consent popups, and age gates can block the target button even when the page is visible.
Embedded login flows: OAuth popups and third-party auth windows are often blocked or unsupported in restricted browser contexts.
Anti-bot interstitials: Cloudflare/reCAPTCHA checks can allow read access but block click progression.
Environment drift: you may validate in one thread/session and run the real task in another where tool capability differs.

Proof rule: Before any production task, require the agent to return one concrete click-evidence artifact from this exact session (target text clicked + resulting page state).

Known-good fallback pattern

When automation isn’t available, split work between the agent and a human:

Agent prepares the exact action plan (fields, copy, links, checks).
You perform the click/login/upload step manually.
Agent validates results and drafts the next step.

Don’t loop on the same prompt: repeating “click it again” won’t unlock missing capabilities. Confirm tool availability first.

Copy/paste prompt for clean handoff

I know this step may require manual browser actions. Please do this: 1) List the exact fields/buttons I need to click. 2) Give me the exact text to paste into each field. 3) Tell me what confirmation I should see after submit. 4) After I finish, I’ll paste results and you continue from there.

When to escalate to #help

You installed an automation connector, but agent still reports read-only behavior.
Connector is installed but auth/session is repeatedly lost.
The same flow worked before and now fails with no config changes.

Support-ready packet

Web action issue report Goal: Exact action that failed (click/login/form/publish): Prompt used: Tools shown by agent in-session: URL involved: Surface/session tested (DM/server/thread/dashboard): Expected behavior: Actual behavior: What changed recently (if anything):

Best practice: design workflows so your agent does planning + QA, while humans handle final gated UI actions unless automation is explicitly configured.