September 2026
Everything that changed in NoClick in September 2026.
Approval rules on every connected account
Every connected account now carries its own approval rules, and they apply to everything that uses it: your agents, your coordinator, and any MCP client. Open Settings → Credentials and click the shield on a connection to reach its Tool permissions page.
A locked action runs nothing until you say so. The call waits, the exact arguments it would send are shown to you, and you approve or decline it.
- The Use without approval row sets everything at once. Read-only lets reading actions run and locks the rest, All lets every action run, and None locks everything, including actions the service adds later. Search the list to lock one action on its own.
- Requests arrive under Needs you on the Dashboard, where you can read the arguments and decide without leaving the page.
- Approving admits one call with exactly those arguments, and it has 30 minutes to run. Different arguments, a second attempt, or a change to the rules each need a fresh approval. An untouched request expires after 24 hours.
- Agents and MCP clients can add restrictions but never remove one. Unlocking happens only on the permissions page, signed in as the connection's owner.
- Operations you allowlist on a tool provider node now carry a lock in the node settings, so you can see and change what needs approval without leaving the workflow.
Improvements and fixes2
API keys work again under Settings → Developer. Creating, listing, and revoking a key failed with an authorization error, because the app and the API sit on different domains and the request was not carrying your sign-in. The page also shows the error when a request fails, rather than appearing to do nothing.
Requests to NoClick's API are faster, and a request that takes longer than five seconds no longer fails with a proxy error. That includes the fallback connection your browser uses when it cannot open a websocket, which was being cut off after about ten seconds.
Your MCP server link has a real success signal
The connect status for a workflow that hosts an MCP server now answers two questions separately instead of showing one spinner for both. A Link ready line names how many tools the link serves right now, with a few of them by name, read straight from your workflow with no client involved. Under it, the client line reads Waiting for your agent to connect until a client calls in, then Connected with the client's name, how many tools it was served, and which ones it can call.
- The waiting line names what makes that client connect. Most clients only write the config when you run their add command and open the connection when a session starts, so the usual fix is to start or restart the client rather than to wait.
- After 45 seconds the panel offers that client's own check command, such as
claude mcp listoropencode mcp list. Those commands list the servers and connect at the same time, so running one turns the status green. - The status also sits on the node. The Connect externally header of an MCP Server node reads Connected, with the client and the tool count, for anyone who opens the workflow later, so you do not have to run the Setup finale again to check.
- When NoClick cannot read handshakes for a moment, the panel says it cannot check rather than reporting that nothing has connected. The link keeps serving either way.
- The client setup guides are re-verified. Claude's custom connectors live under Customize → Connectors, Zed connects to a remote URL without a bridge, and VS Code adds the server with
code --add-mcp.