Grass 2.0 turns your phone into a command center for coding agents

The most interesting thing about Grass 2.0 is not the cloud VM. It is the push notification.

Grass 2.0, described on Product Hunt, is a cloud-based development environment built specifically for coding AI agents. It gives each agent a dedicated virtual machine called a GrassVM that runs persistently, independent of a user’s laptop, power state, or internet connection. The agent keeps working when the lid closes, when the WiFi drops, when the user walks away. That alone is useful. But the architecture that matters is the mobile control plane: when an agent needs a permission, a file write approval, or a confirmation to run a command, the request fires as a push notification to the user’s iPhone. The user taps approve or reject from anywhere, and the agent resumes in under two seconds.

This changes the relationship between engineer and agent. It moves the human from babysitter to remote approver. That shift is the real product.

Grass started as a bandwidth-sharing network. The company’s main site describes a service where over 8.5 million users “earn rewards for sharing unused internet bandwidth with the Grass network.” Users install an app, Grass uses their idle connection for “live data access for real-world applications,” and users earn Grass Tokens via airdrops. The first airdrop on October 28, 2024 distributed 100 million tokens to more than 2 million users. That business model is a decentralized proxy network, a play on distributed infrastructure that sits alongside other “earn while you idle” crypto-adjacent services.

Grass 2.0 is a different bet entirely. It targets the engineer who runs Claude Code, Codex, or OpenCode and wants those agents to work without supervision. The core pain point is session interruption. A coding agent running on a local machine stops when the laptop sleeps, when the SSH session times out, when the user closes the terminal. Context is lost. Progress is wasted. The agent cannot run overnight or through a meeting. GrassVM solves that by providing a non-sleeping virtual machine that maintains state indefinitely.

The mobile permission gateway is what makes this viable at scale. Without it, a persistent agent is a liability. The agent needs to make decisions: write files, install packages, modify configurations. If every action requires the user at a terminal, the persistence advantage evaporates. If no action requires approval, the agent can destroy the environment. Grass 2.0 splits the difference with a push-notification approval system that routes each permission request to the phone. The user sees the exact command or file write and approves or rejects with a tap.

The stated latency is under two seconds. That is fast enough that the agent does not stall meaningfully, and the user does not need to be watching.

The target audience is narrow but growing. Software engineers, DevOps specialists, and AI tool developers who run coding agents for code generation, refactoring, automated testing, and build orchestration. These are the people who have already discovered that agents are useful but that babysitting them is not. Grass 2.0 offers a concrete escape from that loop.

The use cases are predictable but real. Overnight refactoring: dispatch a large-scale code migration before leaving the desk, let the agent run on GrassVM, review the diff on the phone the next morning. Multi-agent experimentation: run Claude Code on one GrassVM and Codex on another for parallel task execution without tying up local resources. Remote monitoring: approve critical file writes from a meeting or a commute.

The product also includes a differential code review interface optimized for mobile. The app presents the agent’s work as organized diffs with added, modified, deleted, and renamed files per repository. This turns code review from a terminal wall into a navigable phone interface. It is a small feature but a necessary one. Without it, the user would have to SSH in to inspect what the agent did, defeating the purpose of mobile oversight.

Grass 2.0 positions itself against standard cloud VMs like AWS EC2. The differentiation is the mobile control plane and the structured diff viewer. A standard VM provides raw compute. Grass adds the agent-specific orchestration layer. The company’s FAQ makes this explicit: “Grass is a specialized cloud development environment optimized for running coding AI agents.”

The pricing model matters for adoption. Grass offers a free tier with 10 hours of VM usage, no credit card required. That is enough for an engineer to test the workflow: set up a GrassVM, deploy Claude Code, walk away, and see whether the push-notification approval model works in practice. If it does, the user upgrades to a paid plan. If it does not, the user loses nothing but time.

The broader implication is for how engineering teams structure agent workflows. The current dominant model is local: the agent runs on the developer’s machine, the developer watches the terminal, the developer approves or rejects actions in real time. This model does not scale. An engineer cannot run three agents simultaneously if each requires constant attention. Grass 2.0’s architecture suggests a different model: the agent runs on dedicated infrastructure, the human supervises via notifications, and the human’s attention is a scarce resource that the agent must request explicitly.

This is the agent-as-a-service infrastructure model. The agent is not a tool the engineer operates. It is a service the engineer manages.

The open question is whether the push-notification model scales to complex workflows. A single approval request for a file write is simple. A chain of ten interdependent approvals, where each decision affects the next, is not. The agent may need to pause for human judgment at a point where the human does not have enough context from a phone screen. Grass 2.0 has not solved that problem. It has solved the simpler problem of keeping the agent alive and giving the human a lightweight approval channel.

The next problem is the harder one: giving the human enough context to make good decisions from a phone, without turning every approval into a research project.