Build a Cloud Toolkit with Warp

Create reusable Warp workflows for safe cloud diagnostics with AI.

Introduction

30 Second Summary

When a website stops behaving, finding the right check can take longer than running it. Rebuilding that check from memory makes small mistakes easy to miss.

In this project, you will build a searchable Cloud Toolkit in Warp with four reusable checks for HTTP status, DNS records, TLS certificate expiry, and listening ports. A Global Rule makes the agent explain every proposed command before you decide whether it runs.

What You'll Build

Your finished Cloud Toolkit turns one fill-in value into a useful diagnostic result from Warp's Command Palette.

By the end of this project, you'll have:

An endpoint check that reports an HTTP status code plus total response time from any URL.
A DNS lookup with a record-type picker covering A, CNAME, MX, and TXT. It returns the domain's matching records.
Two agent-built workflows that reveal TLS certificate expiry plus the process listening on a numeric port. The Global Rule keeps every proposed command behind your approval.
Secret Mission: Create a Toolkit Agent Profile that forces approval before a file deletion. Reject the deletion to prove the file survives.

Are there any prerequisites?

No prior cloud engineering experience is required. You need a macOS device or a Windows 10/11 device with Windows Subsystem for Linux and Ubuntu. The setup steps guide you through Warp, account sign-in, Google AI Studio, and every required command-line tool.

Before We Start

This is your moment to commit to building a reusable Cloud Toolkit in Warp before any setup begins. You will also define why reviewing every AI-proposed command matters before approval.

Get Ready

A reusable toolkit needs a dependable terminal environment. Your diagnostic commands must work before you save them as workflows.

You will prepare Warp with the required command-line tools. You will also connect the model without exposing your API key in a file or command.

In this step, get ready to:

Install Warp and sign in.
Prepare the diagnostic tools in your macOS or WSL2 Ubuntu shell.
Connect Google AI Studio to Warp with Gemini 3.8 Flash.

Install Warp and prepare your shell

This project uses Warp release build v0.2026.10.21.08.25 as its baseline. Choose the tab that matches the Warp installation on your device.

✔️ I have the current Warp build

Press Cmd+Space on macOS or the Windows key on Windows.
Type Warp into the search bar.
Press Enter to open Warp.
Open Settings in Warp.
Select Account.
Open About Warp.
Confirm the installed version is v0.2026.10.21.08.25 or higher.
Complete Warp's sign-in flow.

Warp is open on the required release. Your account is ready for saved workflows.

ⓧ Warp needs an update

Warp can check for a newer stable build from its account settings. Updating now keeps the workflow interface consistent with this project.

Open Settings in Warp.
Select Account.
Click Check for Update.
Complete the update prompt if Warp displays one.
Restart Warp after the update completes.
Return to Account in Warp Settings.
Open About Warp.
Confirm the installed version is v0.2026.10.21.08.25 or higher.
Complete Warp's sign-in flow.

Update not appearing?

Quit Warp before reopening it from your Applications folder or Start menu. A mounted macOS installer can prevent the app from replacing its current build.

Use Warp's official installation guide to replace the older build. Help me update Warp to the required release.

ⓧ Warp is not installed

macOS

Visit the Warp installation guide in your browser.
Download Warp for macOS.
Drag Warp into your Applications folder.
Press Cmd+Space to open Spotlight.
Type Warp into Spotlight.
Press Enter to open Warp.
Complete Warp's sign-in flow.

Warp now opens from Applications. Your signed-in account can store the workflows you create later.

Windows

The Windows installer may ask for system permission. That prompt allows Windows to install the desktop app.

Visit the Warp installation guide in your browser.
Download the Warp installer for Windows.
Run the downloaded installer.
Approve the system permission request if it appears.
Press the Windows key to open the Start search.
Type Warp into the search field.
Press Enter to open Warp.
Complete Warp's sign-in flow.

Warp now opens from the Start menu. Your signed-in account can store the workflows you create later.

Your active shell determines where the diagnostic tools run. macOS supplies the tools already while the Windows path uses Ubuntu inside WSL2.

macOS

Use the macOS shell that Warp opened for the remaining checks.

The macOS shell already includes the five diagnostic tools required for this toolkit. You will confirm each one in the final substep.

Windows

Open a WSL2 Ubuntu session in Warp.
Complete the Ubuntu authentication prompt if sudo requests it.
Install the required Ubuntu packages by running this command:

sudo apt install -y curl dnsutils openssl lsof netcat-openbsd

What does this command install?

The sudo command gives the package action administrator privileges.
The apt install command installs the named Ubuntu packages.
The -y flag answers yes to confirmation prompts.
The dnsutils package supplies dig.
The netcat-openbsd package supplies nc.

Wait for the installation to return to the Ubuntu prompt.
Confirm the package output contains no failed installation messages.

The package download can take a few minutes. The changing package output shows that Ubuntu is still working.

Package installation not completing?

Confirm the active Warp session is an Ubuntu shell inside WSL2. The macOS shell does not use Ubuntu's package manager.

Check that Ubuntu has an internet connection before retrying the installation. Help me troubleshoot these Ubuntu packages.

Connect Gemini without exposing your key

A Google AI Studio API key lets Warp use Gemini 3.8 Flash for agent requests. Warp stores a personal key in the device's secure storage.

A new API key is sensitive. You will move it directly from Google AI Studio into Warp's protected setting.

Sign in to Google AI Studio with your Google account.
Open the API Keys page in Google AI Studio.
Create a Google AI Studio API key.
Copy the new key without sharing it or saving it elsewhere.

That sensitive part is complete. The key is ready to move directly into Warp's protected setting.

Switch back to Warp.
Open Settings.
Search for API keys.
Add the Google key by pasting it into the Google provider entry.
Remove the copied key from your clipboard after Warp saves it.
Open the model picker in Warp's agent input.
Select Gemini 3.8 Flash with the key icon.

Why use the key icon?

The key icon identifies a model that uses your personal provider key. An Auto model uses Warp-provided inference instead.

Your Google key stays in the device's secure storage. It never belongs in a file or terminal command.

Gemini missing from the model picker?

Return to the API keys search result in Warp Settings. Confirm the Google provider entry contains the key you created.

Close the model picker before opening it again. Help me connect Gemini in Warp.

Verify the complete environment

Each workflow depends on a different command-line tool. A version or help response proves that the active Warp shell can reach the command.

Before the check, which command do you expect to give the clearest proof that your cloud toolkit shell is ready.

Verify all five diagnostic tools in the active Warp shell by running these commands:

curl --version
dig -v
openssl version
lsof -v
nc -h

What do these checks prove?

The curl --version check confirms the HTTP client is available.
The dig -v check confirms the BIND DNS utility is available.
The openssl version check confirms the TLS toolkit is available.
The lsof -v check confirms the open-file utility is available.
The nc -h check confirms OpenBSD netcat is available.

Each command prints version or help text. The dig -v result includes a BIND version.

Seeing a missing command?

On Windows, confirm the active Warp session is the WSL2 Ubuntu shell where you installed the packages. A Windows-native shell uses a different set of commands.

On macOS, confirm you are running the checks inside Warp. Help me find the missing diagnostic tool.

Open the model picker from Warp's agent input.
Locate Gemini 3.8 Flash with the key icon.

Gemini 3.8 Flash appears with the key icon. This proves Warp is ready to use your Google AI Studio connection.

Environment checkpoint

The active Warp shell provides curl, BIND dig, OpenSSL, lsof, and OpenBSD netcat.
Warp is installed and signed in.
The active terminal uses a macOS shell or a Warp-connected WSL2 Ubuntu shell.
Gemini 3.8 Flash is selected with the key icon.
The Google AI Studio API key exists only in Warp Settings under API keys.
The key is absent from files, commands, workflows, and prompts.

Your Warp shell and Gemini connection are ready. Next, you will turn your first successful cloud checks into searchable workflows.

Save Your First Workflows

Your diagnostic tools now work inside Warp.

Re-entering diagnostic flags slows every check. Rebuilding a command also creates room for a typo.

A Workflow saves a parameterized command in Personal Warp Drive. This step turns two working checks into searchable tools with fill-in arguments.

In this step, get ready to:

Save a parameterized endpoint status workflow.
Build a DNS lookup workflow with a Static enum.
Run both workflows from the Command Palette.

Save the endpoint check

An HTTP status check reveals whether an endpoint responds. It also measures how long the response takes.

Before you run this check, picture the status you expect from a public example endpoint.

Test the endpoint by running this command in your active Warp shell:

curl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com

What does this command do?

The -s flag hides the progress meter.
The -S flag keeps error messages visible.
The -o /dev/null option discards the response body.
The -w option prints the %{http_code} status plus the %{time_total} transfer time.

Your first live check is working. You will see 200 in ...s with the measured time in place of the dots.

Hover over the successful command Block and click the Save as Workflow icon (⤓).

The workflow editor opens with the successful command ready to edit.

Enter Check if an endpoint is up as the workflow name.
Replace the fixed endpoint with a fill-in argument by entering this command:

curl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" {{url}}

How does the argument work?

The curl flags preserve the status check you just tested.
The {{url}} syntax creates a workflow argument named url.
Warp substitutes the endpoint you enter when you run the workflow.

The editor now shows url as a fill-in argument.

Click Create to save the workflow.
Open Warp Drive with the ⚒ icon in the title bar, then select the Warp Drive tab.
Click + next to PERSONAL, then select New folder.
Enter Cloud Toolkit as the folder name and click Create.

The new Cloud Toolkit folder now appears under Personal in Warp Drive.

Drag Check if an endpoint is up into the Cloud Toolkit folder.

Your first reusable check is ready. Personal Warp Drive now shows Check if an endpoint is up inside Cloud Toolkit.

Can't save the endpoint workflow?

Confirm that you used the Save as Workflow icon on the successful curl command Block.

Check that the command contains {{url}} in place of the fixed endpoint. Help me troubleshoot my endpoint workflow in Warp.

Create the DNS lookup workflow

DNS stores several record types for the same domain. An enum keeps the available record types visible each time you run the lookup.

Hover over the Cloud Toolkit folder in Warp Drive and click its ⋮ menu.
Select New workflow.

The new workflow editor opens inside Cloud Toolkit.

Enter Look up DNS records as the workflow name.
Set the workflow command by pasting this command:

dig +short {{record_type}} {{domain}}

What does this command do?

The dig command queries DNS.
The +short option requests concise output.
The {{record_type}} argument chooses the DNS record type.
The {{domain}} argument supplies the domain to query.

The editor now shows record_type plus domain as separate arguments.

Select the record_type argument.
Choose the enum argument type.

The argument settings now show options for controlling the enum values.

Choose Static as the enum source.
Set the allowed enum values to A, CNAME, MX, or TXT.

The argument preview now shows four record-type choices.

Select the domain argument.
Enter example.com as its default value.

The editor now displays example.com as the starting domain.

Save the workflow.

You now have two reusable checks. The Cloud Toolkit folder contains both workflow names.

Missing an argument option?

Confirm that both argument names still include their double braces in the command. Warp creates the settings only after it recognizes the argument syntax.

Check that record_type uses a Static enum. Help me check my DNS workflow arguments.

✔️ Awesome, I've got everything!

Both workflows are saved inside Cloud Toolkit with their arguments configured.

ⓧ I'd like to double check the full code

The endpoint workflow uses this exact command.

curl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" {{url}}

Endpoint workflow settings

The workflow name is Check if an endpoint is up.
The workflow is saved inside Cloud Toolkit.

The DNS workflow uses this exact command.

dig +short {{record_type}} {{domain}}

DNS workflow settings

The workflow name is Look up DNS records.
The workflow is saved inside Cloud Toolkit.
The record_type argument is a Static enum with A, CNAME, MX, or TXT.
The domain argument defaults to example.com.

Run both workflows

Workflow arguments let one saved command cover several targets. The Command Palette makes each check searchable from anywhere in Warp.

Open the Command Palette in Warp.
Search for DNS.
Select Look up DNS records.
Choose A as the record type.
Press Shift+Tab to move to the domain argument.
Keep the default domain as example.com.
Run the workflow.

You will see IP addresses for the domain. This proves the Static enum value reached dig correctly.

Run Look up DNS records again from the Command Palette.
Choose MX as the record type.
Press Shift+Tab to move to the domain argument.
Keep the default domain as example.com.
Run the workflow.

You will see 0 . in the output.

Why does the MX result look unusual?

The 0 . result is a null MX record. It announces that the domain accepts no mail.

The result confirms that the workflow ran correctly.

Before the final DNS check, predict how changing only the domain affects the MX result.

Run Look up DNS records again from the Command Palette.
Keep MX as the record type.
Press Shift+Tab to move to the domain argument.
Replace the domain with github.com.
Run the workflow.

You will see a real mail exchanger for github.com.

Before the endpoint check, picture the status line you expect from the saved workflow.

Open the Command Palette.
Search for Check if an endpoint is up.
Select Check if an endpoint is up.
Enter https://example.com as the URL.
Run the workflow.

You will see 200 in ...s. Both workflows now accept fill-in values without rebuilding their commands.

Workflow output missing?

Confirm that you selected the saved workflow from the Command Palette. Typing its name without selecting the result does not run it.

Check that the active Warp shell still has network access. Help me troubleshoot my Cloud Toolkit workflow output.

Your Cloud Toolkit now turns endpoint checks plus DNS lookups into searchable commands. Next, you will add a Global Rule before the agent creates the TLS workflow.

Set a Rule and Build a TLS Workflow

Your first workflow made the HTTP check searchable. The second did the same for DNS.

A Global Rule makes the Warp agent explain each proposed workflow command. The rule also requires your approval before execution.

You will use this review gate to build a TLS certificate expiry check.

In this step, get ready to:

Activate a Global Rule for workflow requests.
Review a read-only TLS expiry command before execution.
Save the approved check as the third workflow in Cloud Toolkit.

Create the workflow review rule

Global Rules apply across every project or context in Warp. One rule can therefore protect each future workflow request.

Start Global Rule creation in Warp by entering this slash command:

/add-rule

What does this command do?

The /add-rule slash command creates a new Global Rule. It also opens the Warp Drive Rules pane.

Add the workflow review policy to the new Global Rule by pasting this text:

When I ask for a workflow, show the command first and explain it with one sentence per flag. Wait for my approval before running it. Keep the command read-only with no sudo or rm. Write every value I fill in as a {{argument}}.

How does this rule protect you?

The first sentence makes each proposed command reviewable before execution.
The approval requirement keeps the final decision with you.
The read-only constraint excludes sudo or rm from workflow commands.
The argument requirement preserves fill-in values for later workflow runs.

Use the rule editor's confirmation control to activate the Global Rule.
Return to the Warp terminal pane from earlier.

The Global Rule is now active across Warp agent conversations.

Rule not appearing?

Enter /add-rule in Warp's command input again.
Confirm that the complete rule text appears in the Warp Drive Rules pane.
Use Help me verify my Global Rule setup..

Ask the agent for a TLS workflow

The next request tests whether the rule changes the agent's behavior. The agent should propose a command before it takes any action.

Before you ask, do you think the agent will pause for approval after explaining the proposal?

Ask the Warp agent to draft the TLS expiry workflow by entering this prompt:

Create a workflow that shows when a site's TLS certificate expires.

What should happen now?

The agent should show its proposed command first. It should explain each flag in a separate sentence.

The agent should then wait for your approval. Its wording may differ while these review behaviors remain fixed.

Compare the proposed command with this read-only reference:

echo | openssl s_client -connect {{host}}:443 -servername {{host}} 2>/dev/null | openssl x509 -noout -enddate

What does this command do?

The echo command closes standard input for the certificate connection.
The openssl s_client command opens the TLS diagnostic connection.
The -connect flag targets port 443 on the supplied host.
The -servername flag sends the host through SNI.
The 2>/dev/null redirection hides diagnostic error output.
The pipes pass the returned certificate to the next command.
The openssl x509 command reads the certificate.
The -noout flag suppresses the certificate body.
The -enddate flag prints the expiry date.

Confirm that the proposed command matches the reference command.
Confirm that the agent explained the command one flag at a time.
Confirm that the agent is waiting for your approval.
Request a revision before approval if any command text differs from the reference.

The agent has now explained the read-only proposal. It has also left execution under your control.

Agent skipped the review gate?

Confirm that the Global Rule still contains every sentence from the rule text.
Ask for the TLS workflow again after confirming the rule.
Use Help me diagnose why my Warp agent did not follow the Global Rule..

Approve and save the TLS workflow

A workflow argument makes the certificate check reusable for different sites. The repeated {{host}} placeholder sends the same host to both connection fields.

Enter example.com for the host argument.

Before you approve the run, what kind of expiry detail do you expect the certificate command to return?

Approve the reviewed command for one run.

The output begins with notAfter= and ends with GMT.

Click the ✓ next to the command the agent ran, then the Save as Workflow icon (⤓).
Enter Check when a TLS certificate expires as the workflow name.
Replace both example.com values in the command with {{host}}.
Check that host appears under Arguments.
Click Create.
In Warp Drive, drag the new workflow into the Cloud Toolkit folder.

Cloud Toolkit now contains three workflows. The new entry keeps the host as a fill-in value.

Before the final check, do you expect the saved workflow to return the same certificate date as the approved agent run?

Open the Command Palette in Warp.
Search for Check when a TLS certificate expires.
Enter example.com for host.
Run the saved workflow.

You will see output that begins with notAfter= and ends with GMT.

That review gate has paid off. Your third diagnostic workflow passed human review before execution.

TLS expiry result missing?

Confirm that the saved command matches the reference command exactly.
Confirm that example.com filled both {{host}} positions.
Use Help me troubleshoot this TLS expiry workflow..

✔️ Awesome, I've got everything!

Your Global Rule is active. The reviewed TLS workflow is saved in Cloud Toolkit.

ⓧ I'd like to double check the full code

When I ask for a workflow, show the command first and explain it with one sentence per flag. Wait for my approval before running it. Keep the command read-only with no sudo or rm. Write every value I fill in as a {{argument}}.

echo | openssl s_client -connect {{host}}:443 -servername {{host}} 2>/dev/null | openssl x509 -noout -enddate

Your agent can now extend Cloud Toolkit under a consistent review rule. Next, you will expose a port-name trap that careful command review can catch.

Expose the Port-Name Trap

Your Cloud Toolkit now includes a reviewed TLS expiry check. The Global Rule keeps the agent's next proposal under your approval.

A basic port query can obscure the number you typed by displaying a service name. You'll expose that ambiguity in Warp before improving the check.

In this step, get ready to:

Run a temporary listener on local TCP port 8000.
Expose the service-name substitution in a basic port report.

Prepare a live port target

A listener keeps a local port open so another command can find its owning process. OpenBSD netcat runs this listener in the foreground until you stop it.

Split the current Warp tab to the right by pressing Command+D (macOS) or Ctrl+Shift+D (Windows or Linux).
Start the temporary listener in the new pane by running this command:

nc -l 8000

What does this command do?

The nc command opens network connections.
The -l flag listens for an incoming connection.
The 8000 value sets the local TCP port.

Leave the listener running in the new pane.

The new pane remains occupied by the running listener. Its shell prompt stays unavailable while the port is open.

Listener not staying active?

Confirm the command is running in the new pane.
Check whether another process already uses port 8000 if the listener exits.

If the listener still stops, help me troubleshoot the netcat listener.

Test the basic port report

The listener gives lsof a real network socket to inspect. This basic query asks which process owns the endpoint.

Before you run this, consider whether lsof repeats the number you entered or translates it into a name.

Query the listener from the other pane by running this command:

lsof -i :8000

What does this command do?

The lsof command lists open files such as network sockets.
The -i flag selects Internet network files.
The :8000 filter limits the result to the listener's port.

Find the row for nc in the query output.
Inspect the endpoint beside (LISTEN).

Your output lists nc in the (LISTEN) state. The endpoint shows a service name instead of 8000. On macOS, it reads irdmi.

That mismatch is the intended trap. Name lookup can hide the number you supplied.

Don't see the listener row?

Confirm the nc listener still occupies the other pane.
Check that both commands use port 8000.

If the row is still missing, help me diagnose the port query.

You caught the subtle display trap while the listener is still available for testing. Next, you'll check that the agent preserves the numeric port before saving your fourth workflow.

Review and Save the Port Workflow

Your earlier port check found the listener. Its translated service name hid the numeric port 8000.

The Warp agent can draft the final workflow under your Global Rule. Your review must catch any missing numeric-output flags before command approval.

In this step, get ready to:

Review an agent proposal for a read-only port check.
Require numeric port output through the -nP options.
Finish Cloud Toolkit with a saved port workflow.

Ask the agent for a port workflow

Your request stays broad so the agent has to propose the command. The active Global Rule should make the agent explain its proposal before waiting for your decision.

Before you send the request, do you think the agent will preserve the numeric port without a reminder?

Send this request to the agent in the Warp pane that ran your port check:

Create a workflow that shows what's using a port.

What should happen?

The agent should show a read-only command before running it.
The explanation should cover each proposed flag in its own sentence.
The proposed workflow should keep the port as {{port}}.
Warp should pause so you can review the command before approving it.

You should see a proposed command with a flag explanation. The command remains paused for your approval.

Agent did not pause?

Stop if the agent skips the explanation or approval pause. Confirm that your Global Rule from the previous step remains active.

Do not save an unreviewed result. Help me work out why Warp did not follow my active workflow review rule.

Review the numeric output safeguards

A read-only proposal can still hide the number you entered. The -n option preserves numeric hosts. The -P option preserves numeric ports.

The agent's wording and flag order can vary. Your final proposal should match this cross-platform reference before approval.

Compare the agent's final proposal with this reviewed command:

lsof -nP -i :{{port}}

Why do these flags matter?

The -n option stops host-name conversion.
The -P option stops port numbers from becoming service names.
The -i option selects network files such as listening sockets.
The :{{port}} value filters the output using the port argument.

Check that the agent explains each flag before requesting approval.
Check the proposal for -n and -P. They can appear in any order, together as -nP or apart.
If either is missing, tell the agent about the service-name output from your previous check, and ask it to revise the proposal so the numeric port remains visible.
Ask for the lsof version if an Ubuntu proposal uses a read-only ss alternative.
Confirm that the proposal matches the reference command.
Leave the command waiting for approval.

Proposal still hides the port?

Point the agent to the service name from your earlier output. State that the workflow must preserve the numeric port with both numeric-output options.

Keep the proposal paused until the revision includes -nP. Help me review this port command before I approve it.

Run and save the reviewed workflow

Approval is the human boundary between a proposed command and an executed command. This run should prove that your review fixed the service-name problem.

Before you approve the run, do you expect the output to keep 8000 numeric this time?

Approve the proposed command when Warp asks for permission.
Enter 8000 for the port argument.

You should see nc with TCP *:8000 (LISTEN) in the output. That numeric port proves -nP keeps the number you supplied.

Click the ✓ next to the command the agent ran, then the Save as Workflow icon (⤓).
Enter Show what's using a port as the workflow name.
Replace 8000 in the command with {{port}}.
Check that port appears under Arguments.
Click Create.
In Warp Drive, drag the new workflow into the Cloud Toolkit folder.

Good catch. Cloud Toolkit now has a fourth reviewed workflow that keeps port numbers visible.

✔️ The workflow matches

Your fourth workflow is saved in Cloud Toolkit with port as its argument.

ⓧ I want to double check

The saved workflow is named Show what's using a port. Its command should match this reference.

lsof -nP -i :{{port}}

The temporary listener has finished its job. Stopping it releases the local port after your successful test.

Switch back to the Warp pane running the listener.
Press Ctrl+C to stop the listener.

The terminal prompt returns in that pane. The temporary listener is no longer using port 8000.

Secret mission

Put a Safety Net Under the Agent

Create a Toolkit Agent Profile that places command execution behind your approval. Test its denylist by rejecting a proposed file deletion and proving the file survived.

Clean Up Your Resources

Choose how much of your toolkit to retain. The project stays at no cost within the Warp Free plan plus the Gemini 3.8 Flash free tier.

Cost warning

Warp Free costs $0/month. Gemini 3.8 Flash input and output are free of charge on the Free Tier.

Provider usage can become billable outside free limits. The Pause or Delete options remove Warp's access to your Google key.

Resources you used:

A Personal Warp Drive folder named Cloud Toolkit with four reviewed workflows.
An active Global Rule that governs workflow requests across agent conversations.
An active Toolkit Agent Profile with command approval and denylist protections.
A Google AI Studio API key connection stored in Warp's API keys setting.
A local regular file named practice.txt in the active shell environment.

Keep everything running

Your toolkit is ready for more cloud checks. No cleanup is required while you are still using it.

Leave the Cloud Toolkit folder in Personal Warp Drive.
Keep the workflow-review Global Rule active.
Keep the Toolkit Agent Profile active.
Keep the Google key in Warp's API keys setting.
Keep practice.txt in the active shell environment.

Pause - I'll come back to this later

Removing the key disconnects Warp from your Google AI access. Your saved workflows and safety controls stay in place.

Return to Warp from earlier.
Open Settings.
Search for API keys.
Remove the Google key entry used for Gemini 3.8 Flash.
Leave the workflows, Global Rule, Toolkit profile, and practice.txt in place.

Warp can no longer use that provider key. Your Cloud Toolkit remains ready for your return.

Delete - I don't want to use this again

Complete removal is permanent, so take a moment to confirm that you no longer need the saved toolkit. The steps below remove every project artifact listed above.

Remove the workflows and folder:

Return to Personal Warp Drive.
Expand the Cloud Toolkit folder.
Delete Check if an endpoint is up using its item menu.
Delete Look up DNS records using its item menu.
Delete Check when a TLS certificate expires using its item menu.
Delete Show what's using a port using its item menu.
Delete the empty Cloud Toolkit folder using its item menu.

Remove the Global Rule:

Return to the Warp Drive Rules pane.
Select the Global Rule whose text begins When I ask for a workflow.
Use the rule's delete control.

Remove the Agent Profile:

Return to Settings.
Select Agents.
Select Profiles.
Select the Toolkit profile.
Use the profile's delete control.

Remove the Google key connection:

Return to Settings.
Search for API keys.
Remove the Google key entry used for Gemini 3.8 Flash.

Remove the local practice file:

Delete practice.txt from the active shell environment by running this command:

rm practice.txt

What does this command do?

The rm command removes the local directory entry for practice.txt. With no flags, it targets only the named regular file.

Confirm that Warp returns to the prompt without an error.

Can't remove the practice file?

Return to the same Warp shell environment where you created practice.txt if the command cannot find it.
Help me find and remove practice.txt from the correct Warp shell.

Cleanup is complete. Your Warp project artifacts and local practice file are now removed.

Nice Work!

You did it! Your searchable Cloud Toolkit in Personal Warp Drive now runs four parameterized diagnostics for everyday cloud checks. Command execution stays under human control through your Global Rule plus the Toolkit Agent Profile.

You've learned how to:

Launch four cloud diagnostics from the Command Palette to check an endpoint, query DNS, inspect TLS expiry, or identify a port's listening process.
Build parameterized workflows with reusable text arguments. Restrict DNS choices with a Static enum.
Enforce human command review with a Global Rule that requires flag explanations before execution. Check that the agent-generated port check keeps the numeric-port options before you save it.
Secret Mission: Configure the Toolkit Agent Profile to require approval for file deletion. Reject the proposed rm command to prove the safety control protects the file.

Ready to quiz yourself?