Changelog
What changed in NoClick: the SDK, the API and the app, newest first.
Memories that agents share
A memory is now an object of its own, with a name, that any number of agents can read: what every agent of your company should know, or what one agent learned that another needs. Attach it with memories=; it's read-only unless attached with writable(). Each agent still keeps a memory of its own.
company = noclick.Memory.from_name("company", create_if_missing=True)
company.save("tone", "Warm, brief, no jargon.", description="How we write")
support = noclick.Agent.from_name("support", create_if_missing=True,
instructions="Answer billing questions.", memories=[company])A monthly spending cap for your whole account
Set what your account may spend in each billing period in Settings → Plan and billing. Once the period's spend reaches it, every call that costs money fails with noclick.SpendCapExceeded, its scope "account", until the period resets. What you already have keeps renewing (numbers, domains, storage), and apps keep serving pages until the period reaches twice the cap. Only the account's owner sets or raises it.
Reversible by default: the trash and undo
Deleting an app, database, bucket, dict, queue, repo, volume, inbox or agent now moves it to the trash, where it stays restorable for 30 days. A write that can be taken back records how, so its operation can be undone. Only purging is permanent.
item = noclick.Database.from_name("orders").delete()
print(item.kind, item.name, item.purge_after) # database orders 2026-11-14 ...
item.restore() # back under its name, every table and row with itBuild automations from a description
Workflow.create with instructions has NoClick's builder make the automation, as it does in the app. Change it the same way, by describing the change, and run, pause and publish it from your code.
brief = noclick.Workflow.create(
"Morning brief",
instructions="Every weekday at 8, email me today's calendar and the unread emails that need a reply.",
)
result = brief.latest_build.wait(timeout=900)
print(result.summary)The API is open to every account
Every account, on every plan, can now make keys and call the API, the SDKs and the MCP server. Start with Getting started.
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.