The Claude Code Settings Named in the Exam Guide — MCP, Skills, Hooks and Subagents Tried One by One

In the English exam guide for Google Cloud’s Professional Agentic Architect, the word “Claude” appears exactly once. §2, “Using coding agents for application development”, item 2.1 is about configuring coding agents with MCP servers, skills and tool access, and gives “Antigravity and Claude Code on Google Cloud” as examples. So we mapped the items of §2.1 and §2.2 onto local Claude Code settings and wrote and ran MCP, skills, rules, hooks, subagents and plugins one at a time. This article is the record.

This article contains affiliate links. As an Amazon Associate, we earn from qualifying purchases.

To be clear, we have not taken this exam. This article covers the exam guide as of October 2026, whose PDF text has no revision date, so we cannot say “this setting will be tested”. What we can say is what these settings look like when you trace the guide’s items with a local tool, and how they behaved in this environment. For the certification overview and dates (GA registration opens November 2, 2026, per the October 2026 notice), see What the Google Cloud Professional Agentic Architect Certifies.

One more caveat: in the exam guide, item 2.2 is an Antigravity item, and Claude Code does not appear in it. Practicing 2.2 with Claude Code is our own substitution, not something the guide recommends. We have not used Antigravity; the comparison table for it is built from official materials.

What §2 of the exam guide says

§2 is headed “Section 2: Using coding agents for application development (~17% of the exam)”, about 17% of the exam in the October 2026 guide. It splits into 2.1 “Using coding agents effectively” and 2.2 “Customizing coding agents for enterprise workflows”, each listing items after “Considerations include:”. The original items:

• 2.1, item 1: Configuring coding agents with Model Context Protocol (MCP) servers, custom skills, and access to tools (e.g., Antigravity and Claude Code on Google Cloud)
• 2.1, item 2: Using coding agents in secure sandboxes (e.g., Google Kubernetes Engine [GKE], Cloud Workstations, and Antigravity)
• 2.1, item 3: Using coding agents to refactor source code, optimize execution runtimes, and patch application-layer vulnerabilities
• 2.2, item 1: Creating skills, plugins, extensions hooks, rules, and subagents using Antigravity
• 2.2, item 2: Augmenting Antigravity with Agents CLI to build, scale, govern, and optimize deployed agents

In 2.2 item 1 the original has no comma between “extensions” and “hooks”. We quote it as written and do not treat “extension hooks” as one feature name; what “extensions” refers to is sorted out in the Antigravity comparison section. The guide’s in-scope tool list includes “Antigravity (CLI, SDK, App)”, “Agents CLI in Agent Platform”, “Model Context Protocol (MCP) servers” and “Skill Registry”. Skill Registry is a different thing from where Claude Code or Antigravity keep skills and is not covered here; definitions of the in-scope tools are checked in Agentic Architect Exam Scope: What AI Knows About 28 Tools.

What “Claude Code on Google Cloud” refers to

The exam guide names “Claude Code on Google Cloud” as an example without defining it, so its intent cannot be stated with certainty. A clue is that Anthropic’s documentation has a page with nearly the same name, “Claude Code on Google Cloud’s Agent Platform”, which explains how to use Claude Code through Google Cloud’s Agent Platform (formerly Vertex AI). Agent Platform’s full name is Gemini Enterprise Agent Platform.

The official steps are below; we did not try them, since we avoid using a Google Cloud account for this series.

• You need a GCP project with the Agent Platform API enabled. Request access to Claude models in Model Garden and wait for approval, which the docs say may take 24–48 hours
• Grant the roles/aiplatform.user role. The docs recommend a GCP project dedicated to Claude Code to simplify cost tracking and access control
• To log in, start claude, choose 3rd-party platform on the login screen, then Google Vertex AI (the screen still uses the old name, per the docs)
• To configure with environment variables, set CLAUDE_CODE_USE_VERTEX=1, CLOUD_ML_REGION=global and ANTHROPIC_VERTEX_PROJECT_ID with your project ID
• Confirm with the API provider line in /status

So what changes when you go through Agent Platform? The official “Feature availability” page says “The Claude Code CLI and everything that runs locally work on every provider.” Its list includes subagents, hooks, skills, CLAUDE.md, plugins, MCP servers and the sandbox. Taken at its word, the settings files in this article work unchanged through Agent Platform. The same page notes provider differences for MCP: claude.ai connectors load only when you sign in with a claude.ai subscription, and Tool search — which finds and loads MCP tools on demand — is unavailable on Agent Platform for models older than the Claude 4.5 generation.

Conversely, features that need a claude.ai account sign-in are unavailable via Agent Platform (the desktop app is a partial exception: enterprises can point it at Agent Platform through managed settings). The page lists routines, Remote Control, the Chrome extension, artifacts and Code Review among features unavailable with an Anthropic Console API key or third-party providers. Where routines are useful is covered in Leave Claude Code on Watch with Routines.

We checked Google Cloud’s side too. Google Cloud’s page on Claude models lists the models but never mentions “Claude Code”, and within what we searched, we found no Google Cloud page devoted to Claude Code.

Practice conditions — checking Claude Code settings with the workshop’s three tools

We ran the experiment on October 12, 2026 under the conditions below, trying each setting once (r1 alone was rerun under the same conditions on October 13 to record which instruction files were loaded). Read the results as “this is how it behaved in this environment”.

• Environment: Windows 11, Claude Code v2.1.296 (claude –version), Git Bash installed; the only WSL distribution is docker-desktop
• Login: our normal Claude Code login, not through Agent Platform
• Model: –model sonnet; recorded model ID claude-sonnet-5-5
• Execution: one request at a time with claude -p rather than the interactive screen, with output saved as stream-json
• Surface: Claude Code also runs in the desktop app, VS Code, JetBrains, the web and mobile, and the docs say “the same engine” runs everywhere; we used the CLI only

The command shape is below. We added –setting-sources project to keep personal settings out, and listed in –allowedTools only the tools each run needed. Requests were in Japanese; they are translated in this article.

claude -p "<request>" --model sonnet --setting-sources project --output-format stream-json --verbose --no-session-persistence --allowedTools <only the tools needed for that run>

As the subject we used the workshop’s three tools from Run ADK Agents Locally with Ollama — returning spool stock, returning printer status and reserving a printer — and turned them into an MCP server. Stock and printer status are example values in the code, not a real workshop.

The working project was created outside our usual working folder. Its contents are below, with the plugin in a separate folder.

<working folder>/
    CLAUDE.md
    .mcp.json
    workshop_mcp.py
    orders/order-001.md
    logs/
    .claude/settings.json
    .claude/hooks/block_reserve.py
    .claude/hooks/log_instructions.py
    .claude/rules/orders.md
    .claude/skills/print-preflight/SKILL.md
    .claude/agents/stock-auditor.md
<plugin folder>/
    .claude-plugin/plugin.json
    skills/print-preflight/SKILL.md
    agents/stock-auditor.md

The order file is Markdown listing item, material, quantity, due date and preferred printer (translated):

# Order 001

- Item: phone stand
- Material: PETG
- Quantity: 3
- Due: 2026-10-20
- Preferred printer: p1

An overview of the five runs first; each setting is explained in the sections that follow.

The tools column shows only the parent session’s calls, not calls inside r4’s subagent. Cost is the value recorded in claude -p output (an estimate at list price from token counts, not a bill), and time was measured externally from starting claude -p until it exited: 0.0490–0.0562 USD and 12.6–15.1 s per run.

Adding an MCP server at project scope

MCP (Model Context Protocol) is an open protocol for connecting AI agents to external tools and data; it is not specific to Claude Code, and Antigravity supports it too. The basics of tool calls and MCP are in Wiring a Local LLM Into Real Work — OpenAI-Compatible APIs and MCP. Here we look at the settings for connecting an MCP server to Claude Code.

The official docs recommend HTTP for remote MCP servers and stdio for servers that run as local processes; SSE is deprecated. The workshop server runs locally, so we used stdio, written with the official Python SDK (mcp 2.3.0, MIT license). In the 2.x series, FastMCP was renamed MCPServer.

"""The workshop tools as a local stdio MCP server (official Python SDK, mcp 2.x).

Stock and printer data are made-up example values.
"""
from mcp.server.mcpserver import MCPServer

server = MCPServer("workshop")
STOCK = {"PLA": 4, "PETG": 1, "TPU": 0, "ASA": 2}
PRINTERS = {"p1": {"state": "idle"}, "p2": {"state": "printing", "progress": 0.42}}


@server.tool()
def get_spool_stock(material: str) -> dict:
    """Return how many unopened spools of the given filament material are in stock."""
    m = material.strip().upper()
    return {"material": m, "spools": STOCK.get(m, 0)}


@server.tool()
def get_printer_status(printer_id: str) -> dict:
    """Return the current state of a printer ("idle" or "printing")."""
    p = PRINTERS.get(printer_id.strip().lower())
    return {"printer_id": printer_id, "error": "unknown printer"} if p is None else {"printer_id": printer_id.strip().lower(), **p}


@server.tool()
def reserve_printer(printer_id: str, material: str) -> dict:
    """Reserve an idle printer for a job with the given material."""
    return {"reserved": True, "printer_id": printer_id.strip().lower(), "material": material.strip().upper()}


if __name__ == "__main__":
    server.run()

Register it with claude mcp add. For stdio servers, everything after — is the command that starts the server, and options before — belong to Claude Code itself.

claude mcp add --transport stdio --scope project workshop -- <python> workshop_mcp.py

MCP has three scopes

MCP settings have three scopes — local, project and user — as of the October 2026 docs. The default is local, and local and user are saved in the user’s ~/.claude.json. Project scope is written to .mcp.json at the project root, and the docs recommend sharing it via Git so the whole team uses the same MCP tools. To avoid writing to our ~/.claude.json, we tried only project scope. The resulting .mcp.json, with paths replaced:

{
  "mcpServers": {
    "workshop": {
      "type": "stdio",
      "command": "<working venv>/Scripts/python.exe",
      "args": [
        "<working folder>/workshop_mcp.py"
      ],
      "env": {}
    }
  }
}

What this run showed

In r1 we asked “How many PETG spools are in stock?”. In the startup record (init) the workshop server was connected, with project as its source, and no approval was requested. MCP tools were not loaded up front: Claude first loaded the tool with ToolSearch, then called mcp__workshop__get_spool_stock. The answer was that there is one unopened PETG spool, counted as CLAUDE.md instructs.

No approval was requested for a reason. The docs say interactive sessions ask for approval before using .mcp.json servers, but claude -p and similar runs load them without asking. In other words, running claude -p in someone else’s repository starts whatever servers its .mcp.json lists, without confirmation. Read .mcp.json before you run it.

Permission rules write MCP tools as mcp__<server>__<tool>; in the docs’ example, mcp__puppeteer covers every tool of the puppeteer server. We listed only the tool names each run needed in –allowedTools. For the “access to tools” part of 2.1 item 1, these permission rules and the hooks described later are the relevant practice.

The skill was invoked by a request matching its description

Claude Code’s docs describe skills as something that extends what Claude can do. A skill is a Markdown file named SKILL.md, placed at .claude/skills/<name>/SKILL.md for a project, ~/.claude/skills/<name>/SKILL.md personally, or <plugin>/skills/<name>/SKILL.md in a plugin. Former custom commands have been merged into skills.

All frontmatter fields are optional; only description is recommended, because it is how Claude decides when to use the skill. Two fields are easy to misread. allowed-tools does not restrict tools; it adds tools that can be used without confirmation during the turn that invoked the skill. disallowed-tools removes tools, and disable-model-invocation keeps Claude from loading the skill automatically.

The workshop skill is a pre-print check procedure, with only description in the frontmatter. It was written in Japanese; here is a translation:

---
description: Steps to check material stock and printer availability before printing a 3D print order. Use when asked whether an order file can be printed.
---

# Pre-print check

1. Read the order file and extract the material, quantity and preferred printer.
2. Use `get_spool_stock` to check the material stock.
3. Use `get_printer_status` to check the preferred printer.
4. Return the result in the format below. Do not reserve (reservations wait for human approval).

    Result: can print / cannot print
    - Stock: (material) (spools)
    - Printer: (ID) (state)
    - Reason: (only if it cannot print)

In r2 we asked “Can the order in orders/order-001.md be printed?”. Claude first invoked print-preflight with the Skill tool. The request does not name the skill, so it appears to have been chosen because it matched the description’s “use when asked whether an order file can be printed”. It then read the order file, checked stock and printer status in turn, and answered “can print” in the skill’s format. Following step 4, it did not call the reservation tool. The same answer also noted that it could not confirm whether one spool covers three stands, since neither the order file nor the stock data says how much filament one stand uses. What this run confirmed is the skill invocation and procedure, not whether the material suffices.

/skills lists skills, and /<name> invokes one directly. With one run, we cannot claim a matching description always triggers automatic invocation; it can depend on how the request and description are worded.

When CLAUDE.md and path-scoped rules were loaded

The docs describe CLAUDE.md as “a Markdown file that gives Claude persistent instructions for a project, your personal workflow, or your entire organization”. Large projects can split it into several files under .claude/rules/, and the paths field in YAML frontmatter makes a rule apply only to specific files. AGENTS.md is read by default only when there is no CLAUDE.md (including .claude/CLAUDE.md and CLAUDE.local.md) in the working folder or above; the Project instructions setting in /config can make Claude read both.

The workshop CLAUDE.md is two lines, written in Japanese (translated here):

# Workshop rules

- Write answers in Japanese.
- Count filament spools with the Japanese counter “hon”.

The order-file rule is scoped with paths so it applies only under orders/:

---
paths:
  - "orders/**"
---

# Handling order files

After reading an order file, start the answer with a three-column table of material, quantity and due date.

Recording when each was loaded

You cannot tell from the answer when a rule was loaded. So we attached a hook to the InstructionsLoaded event, which fires when an instruction file is loaded, and appended the whole event to a file. The hook registration is in the settings.json in the next section.

"""InstructionsLoaded hook: append the whole event (which instruction file was loaded and why)."""
import datetime, json, os, sys

event = json.load(sys.stdin)
log = os.path.join(os.environ.get("CLAUDE_PROJECT_DIR", "."), "logs", "instructions.jsonl")
with open(log, "a", encoding="utf-8") as f:
    f.write(json.dumps({"ts": datetime.datetime.now().isoformat(timespec="seconds"), "event": event}, ensure_ascii=False) + "\n")

This hook does not create logs/, so writing fails if logs/ is missing; create it in the working folder before trying. We had created it by hand before running.

There were six records across r2–r5: four for CLAUDE.md with load_reason=session_start and two for orders.md with load_reason=path_glob_match. Both path_glob_match records had order-001.md as the trigger, and matching their session IDs to each run’s output showed they came from r2 and r5, the runs that read the order file.

We had not kept the record for r1 on October 12, so on October 13 we reran r1 under identical conditions (same working folder, request, –allowedTools and –setting-sources project) and confirmed from the record that the only instruction file loaded was the project CLAUDE.md (session_start). The r1 cost and time in the table are from October 12. In the rerun, Claude called the stock tool without arguments and without going through ToolSearch, hit a validation error and called it again with the material — so even under identical conditions, the way tools were called differed from the October 12 r1.

In short, CLAUDE.md was read at the start of the session, and the path-scoped rule was loaded when the target file was read. r2’s answer began with the three-column material, quantity and due-date table the rule asks for, followed by the skill’s check result. Runs that did not read the order file (r3 and r4) have no record of the order rule being loaded. Put always-needed instructions in CLAUDE.md and instructions needed only for certain files in path-scoped rules, and you avoid wasting context.

CLAUDE.md, rules and skills are all instructions written for a model, and they improve as you refine them. A practical book on prompt design for LLMs is useful when you grow those instruction files over time.

Prompt Engineering for LLMs

USD 54.51 on Amazon.com (as of 2026/09/22)

Amazon

ポチップ

Stopping a reservation with a PreToolUse hook

The docs say hooks run automatically at set points in Claude Code’s operation, executing a user-defined shell command, HTTP endpoint, MCP tool call, LLM prompt or subagent. There are five handler types: command, http, mcp_tool, prompt and agent. The table in the docs as of October 12, 2026 lists 33 events (the number can change between versions). PreToolUse, for example, fires before a tool call runs and can block it; Stop fires when Claude finishes responding.

Blocking is signaled by the exit code: exit code 2 means “block” and works only on events that can be blocked, such as PreToolUse. Hooks can be written in ~/.claude/settings.json (all projects), the shareable project .claude/settings.json, .claude/settings.local.json, managed settings, a plugin’s hooks/hooks.json, and skill or subagent frontmatter. On Windows, command hooks run in Git Bash, or in PowerShell if Git Bash is absent; our machine has Git Bash.

For the workshop we wrote a hook that always stops the reservation tool before it runs. The settings.json is below; in the real file we wrapped paths in double quotes in case of spaces, but those quotes are omitted here.

{
  "hooks": {
    "PreToolUse": [
      {"matcher": "mcp__workshop__reserve_printer",
       "hooks": [{"type": "command", "command": "python $CLAUDE_PROJECT_DIR/.claude/hooks/block_reserve.py"}]}
    ],
    "InstructionsLoaded": [
      {"hooks": [{"type": "command", "command": "python $CLAUDE_PROJECT_DIR/.claude/hooks/log_instructions.py"}]}
    ]
  }
}

The blocking script just writes a reason to stderr and exits with code 2 (the message was in Japanese; translated):

"""PreToolUse hook: stop reserve_printer and ask for a human decision (exit code 2 blocks the call)."""
import json, sys

event = json.load(sys.stdin)
sys.stderr.write("Reservation requires human approval (stopped by PreToolUse hook). tool=" + event.get("tool_name", "") + "\n")
sys.exit(2)

What this run showed

In r3 we asked “Please reserve p1 with PLA.”. Claude loaded the reservation tool with ToolSearch and called mcp__workshop__reserve_printer. The hook stopped the call, and the tool result came back as an error saying the reservation requires human approval and was stopped by the PreToolUse hook. Claude then answered that it would not bypass the hook or reserve some other way, and did not look for alternatives.

Note that it was the hook, not the model’s judgment, that stopped it. The project instructions did not include “check status and stock before reserving”, and in this run Claude went straight to reserving without checking either. To make a procedure stick, write it in a skill or CLAUDE.md; to block an operation that must never go through, stop it with a hook. You can confirm which hooks are loaded with /hooks in an interactive session. A way to check afterwards, mechanically, whether an agent called tools in the intended order is covered in ADK Evaluation Locally: What an Evalset Catches and Misses.

The subagent ran in its own context and returned only a summary

The docs describe subagents as AI assistants that handle specific kinds of tasks, each running in its own context window with its own system prompt, tools and permissions. The file is YAML frontmatter followed by the system prompt in Markdown, with name and description required. They live in the project’s .claude/agents/ or in ~/.claude/agents/ for all projects, among other places.

Watch out for /agents. From v2.1.198 it only suggests asking Claude to create and manage subagents and no longer opens a management screen; that screen existed in v2.1.197 and earlier. Today you write the file or ask Claude to create it. Per the docs, if you create the agents folder after a session starts, you need to restart.

Nesting is capped too: subagents that spawn subagents may go up to three levels below the main conversation by default, adjustable with CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH. Our subagent is a stock clerk; with only the stock tool in tools, it can neither check status nor reserve. Its prompt was in Japanese (translated):

---
name: stock-auditor
description: Counts and reports filament stock per material. Use when asked to check stock.
tools: mcp__workshop__get_spool_stock
---

You are the workshop’s stock clerk. Call get_spool_stock for each requested material and return only a list of “material: spools” in Japanese. For materials with zero spools, add “(out of stock)”.

What this run showed

In r4 we asked to use the stock-auditor subagent to count PLA, PETG and TPU. The parent session made exactly one call, the Agent tool with subagent_type stock-auditor. Inside the subagent, the stock tool was called three times, and seven messages carrying parent_tool_use_id (marking the parent-child link) were recorded.

All that came back to the parent was the summary “PLA: 4 / PETG: 1 / TPU: 0 (out of stock)”. The intermediate calls and results never piled up in the parent’s context. For tasks where the parent does not need intermediate results, this keeps the parent context light. Running dozens of subagents from a script is covered in Claude Code Workflows Pin the Script.

Subagents, hooks and tool restrictions are building blocks of agent design in general, not only of Claude Code. A practical book on building agents, from tools to multi-agent systems, helps you see the same patterns across products.

AI Agents in Action, Second Edition

USD 47.48 on Amazon.com (as of 2026/09/22)

Amazon

ポチップ

Bundling into a plugin added a prefix to the names

The docs describe a Claude Code plugin as a folder that installs and loads skills, agents, hooks, MCP servers and more as one unit, for when you want to distribute several of them together. During development you can load it directly from a folder with –plugin-dir, without a marketplace.

Two cautions. First, a plugin cannot contain CLAUDE.md (rules); the docs say to write instructions as skills instead. Second, do not confuse names: VS Code extensions and JetBrains plugins are different things from Claude Code plugins. We bundled the print-preflight skill and the stock-auditor subagent into a plugin named workshop-kit, with the same file contents as in the project. Its marker, plugin.json:

{
  "name": "workshop-kit",
  "version": "0.1.0",
  "description": "The pre-print check skill and the stock auditor subagent, packaged as a plugin."
}

What this run showed

In r5 we loaded the plugin with –plugin-dir and typed /workshop-kit:print-preflight orders/order-001.md. The startup record listed workshop-kit:print-preflight (skill) and workshop-kit:stock-auditor (subagent) next to the same-named project items without a prefix. Plugin items carry the plugin name as a prefix, so identical names remain distinguishable.

Invoked by slash command, Claude followed the skill’s procedure — read the order, check stock, check printer status — and answered “can print”, as in r2, noting that it could not confirm one spool was enough because the order file lacks per-item usage and that it assumed it was. There is no Skill call in r5’s parent calls in the table, presumably because the user invoked the skill directly with a slash command. When distributing skills and subagents to a team, the plugin prefix showing where each came from is useful.

Cautions when trying this — where the working folder lives, and connectors

Four things to watch when trying Claude Code settings locally, each either observed in this run or warned about in the docs.

First, where the working folder lives. Our first r1 ran with the working folder under the user’s home directory, and ~/.claude/CLAUDE.md (the user’s personal instructions) in a parent folder was loaded as “Project” memory — even with –setting-sources project. We moved the folder outside home and reran; the r1 in the table is that second run.

Second, claude.ai connectors. Connectors set up on the claude.ai account were loaded even with –setting-sources project. We did not put connector tools in –allowedTools, and none were called in any of the five runs. But –allowedTools specifies tools that may run without confirmation; it does not limit which tools are available. Indeed, the startup record listed connector tools among the session’s tools. To remove them from the list, use –disallowedTools as the docs say. Even when you think you are testing with project settings only, assume account settings come in separately.

Third, the .mcp.json approval noted in the MCP section: claude -p loads it without approval. Also, testing at local scope writes to the user’s ~/.claude.json. To keep your normal settings clean, test at project scope and remove the whole working folder afterwards.

Fourth, cost and permissions. This run cost 0.0490–0.0562 USD per run (estimated), small in all five. But running claude -p without confirmation cannot be separated from deciding what to allow. What to hand to unattended runs is covered in Decide Claude Code Permissions and Cost Before You Leave It Running.

Items not tried locally — sandboxes, refactoring and vulnerability fixes

We did not try 2.1 item 2 (sandboxes) or item 3 (refactoring, optimization, vulnerabilities) locally; here is only what the official materials say.

Claude Code’s sandbox

The docs describe the Bash sandbox as an OS-enforced boundary around the shell commands Claude runs on your machine. It is off by default and toggled with /sandbox. It runs on macOS, Linux and WSL2; on native Windows, the docs say commands run unsandboxed. Our machine is Windows 11 with only docker-desktop as a WSL distribution, so we could not try it.

Three points matter. Only shell commands are enclosed; file tools, MCP servers and hooks run outside. Read access is broad by default, covering most of the machine including credential files such as ~/.ssh (block them with denyRead). And to enclose everything, choose a dev container or VM; the docs caution that dev containers give substantial protection but no system is fully immune to every attack. The bypassPermissions mode is also meant only for isolated environments such as containers or VMs.

GKE and Cloud Workstations

GKE has a feature called GKE Agent Sandbox. The exam guide does not say it means this, but it is an isolation mechanism for agents: per the docs, it manages isolated, stateful, single-replica workloads on GKE so LLM-generated untrusted code can run safely, isolated with security-focused runtimes such as gVisor. It can also give developers isolated cloud development environments. Agent Sandbox itself has no extra charge, but the resources it creates incur GKE pricing, and it is not built for any particular coding agent.

Cloud Workstations is a managed development environment on Google Cloud. The coding agent its docs feature is Gemini CLI, which is included in every workstation image, and Antigravity’s VS Code extension v1.7.0 added interactive authentication in Cloud Workstations and Cloud Shell. We found no official procedure for running Claude Code in Cloud Workstations or GKE Agent Sandbox in either side’s materials; for Claude Code we searched the 222 doc pages retrieved on October 12, 2026.

Claude Code’s docs do have two other resources for running on Google Cloud or GKE. One deploys the Claude apps gateway on Cloud Run or GKE with Agent Platform as the model upstream; the gateway is your own service between developers’ Claude Code and the model provider, handling sign-in with your corporate identity and model-usage controls. Claude Code itself still runs on developers’ machines, and the docs call this a working example, not a supported production setup. The other is self-hosted environments (public beta on Team and Enterprise plans), which run Claude Code cloud sessions on infrastructure your organization operates; the production docs include a Kubernetes recipe and list GKE Workload Identity as a hardening measure.

Refactoring, runtime optimization and vulnerability fixes

For refactoring, the Claude Code docs have a worked example (the “Refactor code” section of Common workflows). In Antigravity, the CLI’s plan mode lists complex refactoring as a use case, as does the /plan command, and /boost covers tangled multi-file refactors.

For optimizing execution runtimes, Antigravity has a named feature: /boost, which splits a problem across several subagents and iterates on verification. Its stated uses include hard concurrency bugs, algorithm optimization and complex multi-file refactors, and the CLI example asks to vectorize a matrix transpose with SIMD and measure throughput. It is available on paid plans in 2.0 and the CLI. Claude Code has no feature named after runtime optimization; the closest is /simplify, where four agents review the changed code in parallel, one viewpoint being efficiency. In Claude Code, treat optimization, like refactoring, as work you direct.

For finding and fixing vulnerabilities, Claude Code has three main tools. /security-review checks the current branch’s changes for vulnerabilities and needs an origin remote; our empty working folder had none, so we did not try it. The security-guidance plugin has Claude review its own changes against common vulnerabilities while working and fix what it finds in the same session. The Claude Security plugin scans the whole repository, turns chosen findings into proposed fixes, and lets you review and apply them. Code Review, which reviews GitHub pull requests automatically (research preview for Team and Enterprise), also lists vulnerabilities among what it looks for. In Antigravity’s official materials (35 pages retrieved October 12, 2026) we found no feature for fixing vulnerabilities; a “security auditor” appears as an example of how to write a subagent, not as a feature.

Antigravity’s equivalents — a comparison table from official materials

Antigravity is Google’s coding agent, which its docs describe as an agentic coding platform and CLI for orchestrating autonomous subagents, scheduled tasks and interactive code verification. We have not used it; this section rests entirely on official materials retrieved October 12, 2026 (only the hook-event count was rechecked on October 13).

The docs list four surfaces: Antigravity 2.0, the CLI, the SDK and the IDE, plus IDE extensions. The desktop app Antigravity 2.0, unlike its predecessor Agent Manager, is independent of the IDE. The Antigravity CLI (command agy) is a terminal TUI that runs on macOS, Linux, Googlebook and Windows. The Antigravity SDK is a Python SDK installed with pip install google-antigravity. The Antigravity IDE is not offered for enterprises, and IDE extensions exist for VS Code, Visual Studio, JetBrains, Zed and Xcode. The exam guide lists “Antigravity (CLI, SDK, App)”; “App” is probably the Antigravity 2.0 desktop app, but the guide does not say.

Using it requires signing in with a Google account; the CLI and SDK docs describe running with a Gemini API key, and the SDK is used with an API key. The individual plan is generally available at $0 a month with weekly usage limits that vary by plan, and you cannot bring your own API key for extra limits. It is available in Japan and not to anyone under 18. The FAQ says accessing Antigravity from third-party tools violates the terms of service, and that FAQ question names Claude Code. Models are not limited to Gemini; depending on plan, Claude models can be chosen too, though the mapping of models to plans changes in part on November 2, 2026, so we leave out the details. For enterprises it is offered through Gemini Enterprise.

The counts are the number of rows in each doc’s table: Claude Code as of October 12, 2026, Antigravity as of October 13. Antigravity’s table had five events without SessionStart when retrieved on October 12 and six when retrieved on October 13, so note the version when comparing hook-event counts.

What is shared and what differs

MCP is an open protocol, not either tool’s feature. Both say their SKILL.md follows the open Agent Skills standard, but the locations differ: Claude Code uses .claude/skills and Antigravity .agents/skills. Claude Code does not automatically load instruction files or skills under .agents/, though it can read them as files with the Read tool. Other differences: AGENTS.md is read as rules in Antigravity, but by Claude Code by default only when there is no CLAUDE.md. Antigravity plugins can contain rules, while Claude Code puts instructions into plugins as skills. Antigravity has a built-in browser subagent, and Claude Code has a Chrome extension (which needs a claude.ai account sign-in).

Three meanings of “extensions”

In Antigravity’s materials, “extensions” appears in three senses. First, Gemini CLI extensions, which Antigravity imports as plugins; the materials say the industry has converged on the word “plugins” and that agy plugin import gemini brings them in, and the CLI offers a one-time import of Gemini CLI extensions, skills and settings on first launch. Second, IDE extensions. Third, UI extensions, added in 2.0 v2.22.0 (October 8, 2026), which appear in a panel beside the conversation. The exam guide does not say which it means. Claude Code has no feature called an “extension”; its “Extend Claude Code” page simply describes CLAUDE.md, skills, subagents, hooks, MCP and plugins together as ways to extend it.

What “augmenting Antigravity with Agents CLI” means

2.2 item 2 is “Augmenting Antigravity with Agents CLI”. Agents CLI (“Agents CLI in Agent Platform” in the tool list) is published on Google’s GitHub as google/agents-cli — the original repository, not a fork — under Apache-2.0. It was announced on the Google for Developers Blog on April 22, 2026; the version we checked on October 12, 2026 was v1.9.0 (released October 6), and v1.10.0 is also dated October 12.

The README describes Agents CLI as giving coding agents the skills and commands to “build, scale, govern, and optimize” enterprise agents — the same four verbs as 2.2. Agents CLI is not itself a coding agent: it adds CLI commands and skills so that your coding agent handles creating, evaluating and deploying ADK agents on Google Cloud well. It can be used two ways: install its skills into a coding agent such as Antigravity CLI, Claude Code or Codex, or have a person type the CLI commands directly. Every command works standalone, and there are seven skills.

Per its source, the Antigravity integration places the skills installed by agents-cli setup where Antigravity can see them; Antigravity’s own materials (35 pages) say nothing about Agents CLI. The same setup installs skills into other coding agents including Claude Code, and the repository ships both a Claude Code plugin layout (.claude-plugin/plugin.json) and a Gemini extension layout (gemini-extension.json).

§3.1 also has “Configuring skills using Agents CLI (e.g., plugins and agent vs. human mode)”. Whether “plugins” means the repository’s plugin layouts cannot be determined from the guide. Agent mode and human mode are best read in terms of the announcement blog, which says Agents CLI is built to be used by agents but developers also need deterministic control, and describes people running commands directly in the terminal or scripts.

Install with uvx google-agents-cli setup; it needs Python 3.11+, uv and Node.js. Native Windows is not officially supported, so on our machine it would need WSL2; we did not try it. Local development (create, run, evaluate) works with an AI Studio API key, while deployment and cloud features need Google Cloud. Agents CLI does not handle coding-agent authentication; Claude Code uses an Anthropic account or API key. Agents CLI also sends one usage signal per command by default: the record itself is written to the logs of your Google Cloud project, and the request headers that write it also send Google the CLI and Python versions, OS, CPU architecture, command name and a random per-run ID. Set AGENTS_CLI_TELEMETRY=0 or DO_NOT_TRACK=1 to stop it.

What this practice shows, and what it does not

There is a lot this cannot show. Each setting was tried once (r1 twice) with Windows 11, Claude Code v2.1.296 and Sonnet; other versions, models or request wording could change whether skills auto-trigger and how the model behaves after a hook. Sandboxes, /security-review, local scope, Agent Platform access, Antigravity, Agents CLI, GKE and Cloud Workstations were not tried. We cannot know what the exam asks, and since 2.2 is an Antigravity item, if Antigravity’s file locations (.agents/skills and so on) are tested, Claude Code practice alone will not answer them; use the comparison table to map the names. And this practice does not replace the labs on Google Skills.

Still, writing and running Claude Code settings once makes file locations and load timing concrete. In this run the skill was invoked by a matching request, the path-scoped rule loaded when its file was read, the hook stopped the reservation with exit code 2, and the subagent returned only a summary. Having seen this in your own environment makes it easier to tell what is the same and what differs when you read Antigravity’s materials.

Sources

• Professional Agentic Architect exam guide (PDF)
• Claude Code on Google Cloud’s Agent Platform
• Claude Code: Feature availability
• Claude Code: Connect Claude Code to tools via MCP
• Claude Code: Extend Claude with skills
• Claude Code: Memory
• Claude Code: Hooks reference
• Claude Code: Create custom subagents
• Claude Code: Plugins overview
• Claude Code: Commands reference
• Claude Code: Configure the sandboxed Bash tool
• Claude Code: Common workflows
• Claude Code: Deploy Claude apps gateway on Google Cloud
• Google Cloud: Anthropic’s Claude models
• Google Antigravity Docs
• Antigravity: Hooks
• Antigravity: Agent skills
• Antigravity: Plugins
• Antigravity: Boost deep reasoning
• Antigravity: FAQ
• google/agents-cli on GitHub
• Google for Developers Blog: Agents CLI in Agent Platform
• GKE: About GKE Agent Sandbox
• Cloud Workstations: AI agent-assisted coding with Gemini CLI

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.