Dicey Table
Docs
Search the docs

Fix a problem

Fix an agent that won't connect

Why your AI agent won't connect to DiceyTable and how to fix it: refused connections, busy ports, a missing bridge, Windows start-up and version errors.

3 min readVerified

View as Markdown
On this page7 sections

An agent that won't connect usually means the tab and the bridge can't find each other. The bridge is the small program your MCP client runs to link the agent to your tab. Run npx -y @diceytable/mcp-bridge@1 doctor first, then find the message you see below.

If the browser blocked local network access, or you use Safari, the fix is on allow local network access for the bridge instead. If the tab connects but keeps asking for a code, see fix pairing code problems.

"Refused to connect" in the browser console#

What you see. The tab never finds the bridge. The browser console says Refused to connect to ws://127.0.0.1:47621 because it violates the document's Content Security Policy.

Why it happens. The site may reach the bridge only on ports 47621 to 47625. Either the tab is an old cached copy of DiceyTable from before those ports were allowed, or the bridge is on a port outside that range.

Fix it.

  1. Hard-reload the tab: Ctrl+Shift+R, or Cmd+Shift+R on a Mac. An installed DiceyTable app updates the same way.
  2. If you started the bridge with --port, pick a port from 47621 to 47625. doctor warns about a port outside the range.

doctor says a port is in use#

What you see. doctor shows [warn] Port 47621: held by another program.

Why it happens. Another program is listening on that port. Nothing is broken. The bridge moves on to 47622, then 47623, up to 47625, and the tab checks all five.

Fix it. Only if all five ports are taken: close one of those programs, or run the bridge with --port set to a free port in the range.

If doctor says held by a running DiceyTable bridge hub, that is fine too. Another MCP client's bridge got there first, and yours shares it. Several agents can share one hub. If that other bridge is a leftover from an earlier run, fix pairing code problems shows how to clear it.

Why does the tab say no AI agent bridge answered?#

What you see. "No AI agent bridge answered on this computer."

Why it happens. The tab looked for the bridge before the bridge was listening. The bridge opens its port only after the agent calls session_connect.

Fix it.

  1. Ask the agent to connect first. Wait until it shows you a pairing code.
  2. Then open Help ▸ Connect AI agent… in the tab and type the code.
  3. Still nothing? Check that your MCP client started the bridge. In Claude Code, /mcp should list diceytable as connected. Then run doctor.

The tab never says Agent connected#

What you see. You typed the code, but Agent connected never shows. Work down this list:

Cause How to tell Fix it
You denied the consent dialog, or it timed out session_list_tabs shows the tab as not paired Open Connect AI agent… again and type a fresh code.
The code was wrong or ran out The dialog says That code did not match, That code has expired or Too many wrong codes See fix pairing code problems.
AI agent access is off The bridge reports agent-access-disabled Turn on Allow AI agents to connect to DiceyTable as you in Settings ▸ AI agents.
The tab uses a different account from the key Pairing fails with ticket-user-mismatch Sign the tab in to the key's account. status shows which account that is.
The pairing ticket ran out Pairing fails with ticket-expired Ask the agent to reconnect.
Your computer's clock is wrong doctor shows [warn] Clock Set your clock to update by itself.
You aren't signed in The dialog never opens Sign in. Agent tools exist only in a signed-in tab.

A pairing ticket is a short pass the server gives the bridge so the tab can join. It lasts 5 minutes, and the bridge renews it every 30 seconds while it runs. A clock that is a few minutes off makes a fresh ticket look expired, which is why the clock matters.

Why won't the bridge start on Windows?#

What you see. Your MCP client says diceytable failed to start, or the bridge stops right away.

Why it happens. Usually Node.js is missing or too old, or the client can't run npx directly.

Fix it.

  1. Open a new terminal and run node --version. It must print 20.19 or newer. Your MCP client uses the same PATH, so restart the client after you install Node.js.

  2. If the client can't start npx, wrap it in cmd /c. For Claude Code:

    Shell
    claude mcp add diceytable -- cmd /c npx -y @diceytable/mcp-bridge@1

    In a JSON config, set "command": "cmd" and "args": ["/c", "npx", "-y", "@diceytable/mcp-bridge@1"].

"Your DiceyTable bridge is too old" (or too new)#

What you see. The tab names your bridge as too old or too new, and gives a line to run, such as npx -y @diceytable/mcp-bridge@1.

Why it happens. The bridge and the site speak different major versions of their protocol.

Fix it. Run the exact line the message gives, then restart your MCP client. @1 always fetches the newest 1.x bridge. After a new major version ships, the site keeps accepting the old one for at least 90 days.

A single tool that answers tool-unavailable is the same story in miniature. Your bridge knows a tool the site doesn't have yet. The bridge command line reference explains how versions work.

Next steps#

Did this page answer your question?