For Agents
Start, authorize, and manage a user's Google Cloud Shell environment, including SSH public keys for remote access. Lets agents drive a managed Linux session attached to the user's GCP identity.
Get started with Cloud Shell API in minutes using your preferred integration method.
# Add to your MCP client config (Claude Desktop, Cursor, Windsurf)
{
"jentic": {
"url": "https://api.jentic.com/mcp",
"auth": "oauth"
}
}
# Then ask your agent:
"start cloud shell environment"
# → Jentic returns the GET /events tool with parameter schema, agent executes.What an agent can do with Cloud Shell API API.
Start a user's Cloud Shell environment and poll until it is RUNNING
Authorize a Cloud Shell session with short-lived gcloud credentials
Add and remove SSH public keys attached to the environment
Cancel an in-flight start or authorize operation
Get the current state of the Cloud Shell environment
GET STARTED
Use for: I need to start my Cloud Shell environment, Authorize a Cloud Shell session with gcloud credentials, Add an SSH public key to my Cloud Shell environment, Remove a stale SSH public key from Cloud Shell
Not supported: Does not provision custom VMs, execute shell commands directly, or persist user files outside the environment — use for managing the lifecycle and SSH access of Google Cloud Shell sessions only.
The Cloud Shell API lets users start, configure, and connect to interactive shell sessions running on Google-managed VMs preloaded with the gcloud SDK and common developer tooling. Programmatic callers can fetch the user's environment, authorize an SSH session, and manage the public keys used to connect from local clients. It is most often used to embed a one-click shell experience into developer tools, training apps, and onboarding flows that need a real Linux environment without provisioning infrastructure.
Patterns agents use Cloud Shell API API for, with concrete tasks.
★ One-Click Tutorial Sandboxes
Embed a Cloud Shell session into a learning app so users land in a configured Linux environment with gcloud installed and authenticated. The API starts the environment on demand and authorize returns short-lived credentials so the session can run gcloud commands against the user's own project, eliminating the need to ship a virtual machine image with each tutorial.
Call environments.start on users/me/environments/default and poll the operation until state is RUNNING, then return the SSH connection details
Remote SSH Key Management
Manage the SSH public keys attached to a user's Cloud Shell environment so that local IDEs and CI runners can connect into the same managed VM. The API exposes addPublicKey and removePublicKey operations so devops teams can rotate keys on a schedule without users opening the Cloud Shell web UI.
Add a fresh ed25519 public key to users/me/environments/default and remove any keys older than 90 days
Headless Cloud Shell Sessions for Scripts
Spin up a Cloud Shell environment from a script, run a sequence of commands using the authorized credentials, and tear down at the end. This pattern is useful when you want a script to inherit the user's gcloud context without bundling service account keys, and the API's start/authorize/cancel surface gives enough lifecycle control for headless use.
Start the user's Cloud Shell environment, call authorize to get short-lived gcloud credentials, run gcloud projects list, and cancel the start operation when finished
Agent-Driven Developer Onboarding
An AI assistant that helps developers join a new project can spin up the user's Cloud Shell, push the right SSH key, and walk them through their first commands. Through Jentic the agent searches for 'start cloud shell environment', loads the schema, and avoids hardcoding the Cloud Shell resource paths.
Use Jentic to start users/me/environments/default and add the agent's generated public key so a follow-up SSH command can connect
7 endpoints — the cloud shell api lets users start, configure, and connect to interactive shell sessions running on google-managed vms preloaded with the gcloud sdk and common developer tooling.
METHOD
PATH
DESCRIPTION
/v1/{+name}:start
Start the user's Cloud Shell environment
/v1/{+name}:authorize
Authorize the environment with short-lived credentials
/v1/{+environment}:addPublicKey
Add an SSH public key to the environment
/v1/{+environment}:removePublicKey
Remove an SSH public key from the environment
/v1/{+name}:cancel
Cancel an in-flight start or authorize operation
/v1/{+name}:start
Start the user's Cloud Shell environment
/v1/{+name}:authorize
Authorize the environment with short-lived credentials
/v1/{+environment}:addPublicKey
Add an SSH public key to the environment
/v1/{+environment}:removePublicKey
Remove an SSH public key from the environment
/v1/{+name}:cancel
Cancel an in-flight start or authorize operation
Three things that make agents converge on Jentic-routed access.
Credential isolation
Google OAuth 2.0 refresh tokens for Cloud Shell are stored encrypted in the Jentic vault. Agents only ever see scoped short-lived access tokens, and SSH key material added via the API can be generated per session rather than reused.
Intent-based discovery
Agents search Jentic for intents like 'start cloud shell environment' or 'add ssh key to cloud shell' and Jentic returns the matching environments operation along with its request schema, so the agent does not need to read Cloud Shell's discovery doc.
Time to first call
Direct integration with Cloud Shell: 1-2 days for OAuth setup, environment lifecycle handling, and SSH key plumbing. Through Jentic: under 30 minutes — search, load schema, execute.
Alternatives and complements available in the Jentic catalogue.
Compute Engine API
Provisions full custom VMs instead of a managed shell environment
Use Compute Engine when you need a long-lived VM with custom hardware or images; use Cloud Shell when a short-lived gcloud-ready session is enough
Identity and Access Management (IAM) API
Manages the GCP roles a Cloud Shell user can exercise from inside the session
Pair with IAM when you need to scope what the user can do once their Cloud Shell session is authorized
Cloud Resource Manager API
Provides the project context a Cloud Shell session typically operates against
Use Resource Manager to look up or create the project that the Cloud Shell session will target via gcloud
Specific to using Cloud Shell API API through Jentic.
What authentication does the Cloud Shell API use?
It uses Google OAuth 2.0 with the https://www.googleapis.com/auth/cloud-platform scope. Through Jentic the OAuth refresh token lives in the Jentic vault and the agent only ever sees a short-lived access token at execution time.
Can I start a user's Cloud Shell environment with the API?
Yes. Call POST on /v1/{name}:start with the environment resource (typically users/me/environments/default). The endpoint returns a long-running operation that resolves once the VM is RUNNING and ready to accept SSH connections.
What are the rate limits for the Cloud Shell API?
Cloud Shell environments are rate-limited per user, with restrictions on how often start can be invoked and a weekly cap on session hours per user. Programmatic callers should poll the get endpoint with backoff rather than retrying start in a tight loop.
How do I add an SSH key through Jentic?
Search Jentic for 'add ssh key to cloud shell', load the environments.addPublicKey schema, and execute the call against /v1/{environment}:addPublicKey with the key in OpenSSH format. Jentic returns the schema so the agent does not need to memorise the request body.
Is the Cloud Shell API free?
Cloud Shell is included free for users with an active Google account, subject to weekly usage quotas. The API has no per-call charge — you only consume the user's underlying Cloud Shell allocation.
Can the API run shell commands directly?
No. The API only manages the lifecycle of the environment and its SSH keys. Once the environment is RUNNING and authorized, your client connects via SSH to execute commands.