Allow a site
Where restricted network access is turned on, choose which sites and services a workspace and its agent can reach, see what was refused, and allow a site in one click.
On this page9 sections
What a workspace can reach#
With restricted network access on, a workspace, the agent, the commands it runs and its browser can reach only:
- The few services Refactor needs to run a workspace. Connections lists them under Platform, each with its reason.
- The sites allowed by the workspace's network access setting.
- The sites people have added for it.
Everything else is refused. The agent cannot change any of this. When it is refused a site it needs, it says so and a person decides.
Network access settings#
Each workspace has one of three settings. The Connections view in the workspace's left bar shows which one applies, in a sentence.
| Setting | What the workspace can reach |
|---|---|
| Trusted sites | The trusted sites list, plus the sites added for it. This is what a workspace starts with. |
| Added sites only | Only the sites added for it, and the few services listed under Platform. |
| Any site | Anything. Nothing is refused. |
A change reaches open workspaces within a few minutes.
The trusted sites list#
The trusted sites list is maintained by Refactor. It covers the common places development work needs, so that fetching code and installing packages works without anyone having to allow each one:
- Code hosts, such as GitHub, GitLab and Bitbucket.
- Package sources for JavaScript, Python, Ruby, Rust, Go, Java and other languages.
- Linux package mirrors.
- Public container registries.
- Documentation and command-line tool downloads for the main cloud providers.
In the Connections view, Trusted sites lists each group. Open a group to see every site in it and why it is there.
One more group, Anthropic, is listed only while your organization has an Anthropic model turned on in Settings, Models. It lets a script or a tool in the workspace call Claude with your own key. If an organization admin turns every Anthropic model off, the group goes and open workspaces stop reaching those sites within a few minutes. The agent itself keeps working with whichever models are still on: it does not use these sites.
The list leaves out sites whose purpose is to accept uploads from anyone, such as paste sites, file sharing and general cloud storage. If your work needs one of those, add it yourself.
Allow a site when the agent is refused#
When the agent is refused a site during a conversation, a card appears in that conversation naming the site.
- Read the site's name and decide whether the work needs it.
- Choose where to allow it if you are offered a choice: this workspace, its service, or the whole organization.
- Tick also its subdomains if the work needs addresses under it, such as
files.example.comunderexample.com. - Click Allow.
The agent can use the site on its next attempt. You can allow a site for a workspace you can edit. Allowing one for a whole service or the whole organization needs an admin.
Add or remove a site yourself#
- In the workspace, open Connections in the left bar.
- Click +, then type the site's address or paste a link to it.
- Tick Also allow its subdomains if you need them.
- Press Enter.
To stop allowing a site, point at it in the list, click the ×, and confirm. The agent is refused it from its next attempt.
See what was refused#
The card stays in the conversation while the page is open and is gone when you reload. To see what was refused earlier:
- In the workspace, open Connections in the left bar.
- Click Refused connections. The number beside it counts refused sites that are still not allowed.
The tab lists each site the workspace was refused in the last 14 days, when, how often, and what asked for it: the agent, a person or a page in the workspace's browser, a command the agent ran, or a command in a terminal. Click Allow beside a site to allow it. A site that has been allowed since is marked Allowed now.
Organizations that handle health data#
Refactor can mark an organization as handling health data. In such an organization:
- Every workspace is set to Added sites only, and this cannot be changed for a workspace.
- Any site is never available.
- A site for one workspace is added by an organization admin or by an owner of that workspace.
If you can edit a workspace but are not an owner, you can still ask:
- Open Connections, click +, type the site's address and click Send request. On a refusal card in a conversation, click Send request.
- Fibo tells the workspace's owners and your organization's admins that a request is waiting. The message does not name the site. The person who asked is not told about their own request.
- An owner or an admin sees the request under Requests in the workspace's Connections view, and a number on the Connections icon. They click Allow or Decline.
You can withdraw a request you sent while it is waiting.
Let the agent upload files to a site#
Allowing a site lets the workspace reach it. It does not let the agent's browser put the workspace's files into a page on it.
To allow that for one site, open Connections, point at the site, and click the upload control beside it. You are asked to confirm, because this widens what can leave the workspace. The site is then marked Uploads. Click the mark to turn it off again.
In an organization that handles health data, only an organization admin or an owner of the workspace can turn uploads on or off for a site. If you can only edit the workspace, the control is not shown.
Related#
- Security and data explains how network access fits with the rest of Refactor's protections.
- GitHub repositories covers what the agent can do in a repository bound to a workspace, which does not depend on these settings.