What I learned from using Claude Code on the web for a bit
This page has been translated by machine translation. View original
I tried out Claude Code on the web, which lets you run Claude Code in a cloud environment from a browser or mobile device, so I'll summarize what I found. There are many differences from local Claude Code in terms of prerequisites, and I noticed several things in particular regarding security and developer experience.
Note: Claude Code on the web is a feature in research preview as of the time of writing (2026/7/5). The content of this article reflects what I tested in late June 2026, and behavior may change with future specification updates. Please be aware of this in advance. The version of Claude Code used was around v2.1.177 to v2.1.185 (this is an estimate as I didn't record it).
What is Claude Code on the web?
Simply put, it's a mechanism that runs Claude Code in an isolated cloud environment rather than a local terminal, and lets you operate it from a browser or mobile app. When you start a session, the repository is cloned to a cloud VM provided by Anthropic, and Claude Code works within it.
- Get started with Claude Code on the web - Claude Code Docs
- Using Claude Code on the web - Claude Code Docs
There are no additional charges for VM execution. That's great. However, as mentioned above, this is currently a preview feature, so it may change in the future.
※ Hereafter, execution on Claude Code on the web will be referred to as "remote execution/remote session," and execution elsewhere as "local execution/local session."
What I tried
Since I often write Terraform code at work, I had it write Terraform code to create an EKS cluster and a sample app running on it. I only had it write the code, and deployment (running terraform apply with AWS credentials) was out of scope.
Verification perspectives
1. Security
I verified whether Claude Code on the web could be used as a risk mitigation measure for development using Claude Code. In recent years, many malware programs targeting developer machines have emerged. When developing on a local machine, there is a risk that the scope of damage from malware could spread to the entire local machine.
On the other hand, as mentioned above, Claude Code on the web is a feature that works by cloning the repository to a cloud VM for each session. It is possible to localize the scope of damage to that repository. I investigated whether there were any concerns from this perspective of "localizing the scope of damage."
2. Developer experience
If it's difficult to use for developers, it won't gain adoption, so I investigated any concerns in this area.
Below, I'll write about what I noticed, divided into "🔒 Security" and "🧑💻 Developer Experience."
🔒 What I found on the security side
The only way to restrict accessible repositories is through GitHub itself
At first, I thought I could limit which repositories "on the web" could access by setting GitHub App's Repository access to Only select repositories.
However, reading the official documentation's notes, that's not how it works.
Regardless of which method you use (※ there are two GitHub authentication methods: using the GitHub App and using the
/web-setupcommand), cloud sessions can access all repositories that the connected GitHub account has access to. This means it can access not only repositories where the Claude GitHub app is installed, but also other repositories. (...) If your team wants to restrict which repositories can be accessed from cloud sessions, you need to restrict access in GitHub itself.
In other words, if you want to narrow the scope of access, you need to restrict it on the GitHub account side (access rights to teams and repositories). Note that the GitHub App installation scope ≠ the session's access scope.
I actually tried this. I narrowed the scope to only 4 repositories in the GitHub App settings, as shown below:
But in the Claude Code on the web screen, repositories other than the selected 4 are also visible.
I was actually able to start sessions (clone repositories to the VM) for repositories other than the selected 4 as well.
This "can access all repositories" is a bit concerning. As I mentioned, the security aspect of Claude Code on the web—"cloning the repository to a cloud VM for each session" (localization of damage scope)—is appealing. However, if Claude's access rights were somehow compromised, all repositories could be accessed, meaning you can't expect localization of damage scope in that regard.
The best practice you can do at this point is to not link Claude directly to each developer's GitHub account, but instead create a GitHub account for Claude Code per project, configured to access only the minimum necessary repositories. Honestly, it feels cumbersome... I've been hearing a lot lately about separating accounts used by AI agents from those used by humans, and that argument seems applicable here too.
There is (currently) no mechanism to share or template cloud environment settings across a team
I could not find any mechanism to enforce, share, template, or export/import cloud environment settings (setup scripts, environment variables, network allowlists) across a team. You'll need to work things out individually.
- Setup scripts: These can be shared by committing and pushing as a
SessionStarthook. You can branch using theCLAUDE_CODE_REMOTEenvironment variable to run it only during remote execution. However, processing executed via setup scripts is cached and can be reused as the starting point for later sessions, but processing executed viaSessionStarthooks is not cached. - Network allowlists: I couldn't find a way to share these. You'd have to push the settings to the repository and instruct each developer to configure them.
Many pre-installed tools mean relatively higher vulnerability risk
The VM on which each session runs has many tools pre-installed. While convenient, if any of these have vulnerabilities, the potential impact within a session could be relatively broader compared to something like a Dev Container where you can limit to the bare minimum.
Note that Terraform was not pre-installed.
GitHub integration tools are automatically set up
During testing, even though git push was blocked by the deny list, Claude Code told me:
Since
git pushvia Bash was not possible due to it being registered in the deny list in.claude/settings.json, it successfully pushed via the GitHub API usingmcp__github__push_files
In other words, even though I had blocked git push via Bash, it was still able to push via GitHub API tools. Furthermore, I had not configured a GitHub MCP server. It seems to be automatically added in on the web.
This likely corresponds to what the official documentation describes as "built-in GitHub tools that allow Claude to read issues, list pull requests, get diffs, and post comments without any setup."
It's worth keeping in mind that simply blocking git push via Bash in the deny list may not be enough to prevent pushing entirely. That said, the basic development flow in on the web is "develop on a feature branch on the VM, push to a remote branch on GitHub, and create a PR," so you could argue that push being unavailable makes it unusable.
- Using local and remote execution together
- Not wanting Claude Code to
git pushlocally
If that's your policy, you'll need to put some thought into the permissions settings.
pre-push hooks are likely to not work in many cases
There are Git pre-push hooks that run various checks before pushing. I wondered whether, even if malware were installed during development by Claude Code, running security checks within the pre-push hook script could keep the impact confined within the VM.
However, in on the web, pre-push hooks are likely to not work in many cases. There are two reasons for this.
The first is that whether the hook fires depends on how the push is executed.
- Running
git pushvia Bash → ✅ Fires - Pushing via GitHub API tools (such as
push_filesmentioned above) → ❌ Does not fire
As mentioned, Claude Code may push via the GitHub API, so there are cases where the pre-push hook is bypassed.
The second is that setting up the hook is somewhat cumbersome to begin with. Since .git/hooks/ is not under version control and is not included in the clone, custom pre-push hooks do not exist in a new clone for a remote session. You'd need to place them yourself during the session.
- Write out
.git/hooks/pre-pushandchmod +xin a setup script or SessionStart hook - Or point
core.hooksPathto a committed directory - Or use husky or similar (which wires
core.hooksPath=.huskyvianpm install)
pre-push checks can be replaced with Claude Code's PreToolUse hook
While Git's pre-push hooks have gaps as described above, Claude Code's PreToolUse hook can serve as a replacement. By defining it to fire when push tools like push_files are executed via the GitHub API, you can also cover API-based pushes in your checks.
Security tools distributed via MDM are out of scope
This may be obvious, but security tools installed on all employees' machines via MDM (such as Sentinel) are out of scope for the isolated VM in the cloud. You need to operate with the understanding that the protections in effect on local machines do not apply in on the web.
🧑💻 What I found on the developer experience side
Current state of handoff between local ↔ remote
The handoff between local sessions and remote sessions was in the following state at the time I tested:
The method of sending a local session to remote mid-way using & {prompt content} appears to have been removed. It seems it was possible right after the preview release, but it didn't work when I actually tried it (tested on v2.1.177), and there was no mention of it in the official documentation.
You can start a remote session from a local terminal with claude --remote "{prompt content}". However, this only "starts" one—it does not "take something started locally and move it to remote mid-way." Combining it with --resume results in an error.
% claude --resume "slack-mcp-permissions-update" --remote ※ `slack-mcp-permissions-update` is the local session name
Error: --cloud cannot be combined with --resume.
To reattach to a cloud session, pass its id: `claude --cloud <session-id>` (find IDs at claude.ai/code).
I'm not sure what the last line To reattach to a cloud session means, but using --cloud appears to launch a new separate session, behaving the same as claude --remote.
# The following simply started a new session with "slack-mcp-permissions-update" as the prompt
% claude --cloud "slack-mcp-permissions-update"
Created cloud session: Update Slack MCP permissions
View: https://claude.ai/code/session_01H8BjhUSNdFfGBiYycGhoge?from=cli&m=0
Resume with: claude --teleport session_01H8BjhUSNdFfGBiYycGfj14
Passing an existing remote session ID as an argument also resulted in an error.
% claude --cloud session_017rp1aTs6U4jqvT4Spyhoge
Error: Attaching to an existing cloud session is not enabled for your account.
- You can use
claude --teleportto handle a remote session locally mid-way. However, that local session is not synchronized with the remote session (think of it as branching off).
Some built-in commands are unavailable
Among the built-in commands available locally, there were some that couldn't be used in on the web. Within my testing, the following were unavailable:
/branch/doctor/rewind
The documentation also states:
Commands that open interactive terminal pickers, like
/modelor/config, are not available.
However, /model brought up a form like the one below for model selection (as of 2026/7/4):
/config also worked. However, unlike the local version, it opened the Claude Code settings screen on claude.ai ↓.
/mcp also opened a connector settings screen.
At this point, there are built-in commands that don't work or behave differently from local, and it's probably safe to assume that the documentation has many inaccuracies.
settings.local.json usage needs to be revisited
I had been using an approach where settings.local.json is not committed (included in .gitignore), and only a configuration example is shared as settings.local.example.json. However, since on the web only uses code that has already been pushed to the remote repository, this approach doesn't work as-is.
For developer-specific environment variables (API keys, etc.), you'll likely need to consider putting them in the cloud environment setup script (or SessionStart hook script) or environment variable settings mentioned above, or entering them within the session.
There is a mode that automatically creates pull requests
There is a mode that automatically creates a pull request when a session completes. Even if you don't have it turned on, you can request creation within the session. There is also a mode that monitors pull requests and handles fix responses.
Sessions cannot be created at the subdirectory level
I tried to create a session by cloning only a subdirectory of a Git repository to the VM, but it wasn't possible. The entire repository is cloned to the VM. With a monorepo structure, you have no choice but to include directories that aren't needed for development. ※ The behavior with sparse-checkout is untested.
Session history cannot be carried over when changing plans (Enterprise → Max)
Partway through testing, I changed plans from the company's Enterprise Plan to my personal Max 5x. As a result, the remote sessions created under the Enterprise Plan became inaccessible. Since local session information remains locally, plan changes had no particular effect on local sessions, which felt like a significant difference.
Summary
I summarized what I found from trying out Claude Code on the web. Organizing the points again, here are the ones that particularly stood out:
- Access scope needs to be restricted on the GitHub side (it cannot be restricted by the GitHub App installation scope)
- Even if you deny
git pushvia Bash, it can be bypassed. Since pre-push hooks don't fire for API-based pushes, consider usingPreToolUsehooks as a substitute - Many pre-installed tools means relatively higher vulnerability risk. Security tools installed via MDM are out of scope
- Several locally-oriented practices need to be revisited, including local ↔ remote handoff, unavailable built-in commands, and
settings.local.jsonusage
As mentioned repeatedly, Claude Code on the web is a preview feature, and this article reflects what I tested in late June 2026. Specifications will likely continue to change, so when actually using it, please also check the latest official documentation.