Audit Your Coding Agent's Network

Probe and restrict your coding agent's sandbox network access.

Introduction

30 Second Summary

Giving an assistant permission to work in your project can also give it paths beyond your files. Without a quick test, those paths stay invisible.

In this project, you will build a small network probe in a repository you own. You will use it to measure how your coding agent's sandbox changes network access after you enforce an allowlist.

What You'll Build

Your final demo shows one approved host responding while your coding agent names the unrelated hosts that its sandbox blocked.

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

  • A repeatable network probe that checks an expected host, an unrelated public host, and a local network address.
  • A strict allowlist that lets you watch unlisted hosts change from reachable to denied.
  • A results table that compares terminal access with sandbox access before and after enforcement. It also records whether the local network address was blocked separately.
  • Secret Mission: An optional challenge to push your sandbox testing skills further.

Are there any prerequisites?

You need a coding agent that can run commands, curl, and a repository you own. The project costs $0 and requires no new account.

Before We Start

This project compares what your normal terminal can reach with what your coding agent can reach from its sandbox.

A reliable comparison needs one repository that stays consistent across every test. That repository will hold the probe script, settings file, and results table later.

You will confirm that curl works in a normal terminal. You will also confirm that your coding agent can run a harmless command inside the repository.

In this step, get ready to:
  • Select a local repository that you own.
  • Confirm that a normal terminal can run curl.
  • Confirm that your coding agent can access the repository and identify the three probe targets.
Choose a repository you own

The probe will create a script, a settings file, and a results table. Using a repository you own gives you a safe place to keep those artifacts.

  • Use your operating system's file browser to locate a repository you own.
  • Confirm that you are comfortable adding the three project artifacts to that repository.

You now have a safe home for the probe. Keep the repository location handy for your coding agent.

Open a normal terminal and check curl

Your normal terminal provides the baseline for the network comparison. The agent run only becomes meaningful when you can compare it with the same tool running outside the sandbox.

macOS

  • Press Command-Space bar to open Spotlight.
  • Type Terminal into the search field.
  • Press Return to open Terminal.

Windows

  • Press the Windows key to open search.
  • Type Windows Terminal into the search field.
  • Press Enter to open Windows Terminal.

Linux

  • Open your operating system's application launcher.
  • Search for your installed terminal application.
  • Select the terminal application from the results.
  • Confirm that curl is available by running this command:
curl --version

The first output line starts with curl and shows its installed version. Good, your normal-terminal baseline is ready for the comparison.

Is curl unavailable?

  • Use the official curl website to find the supported installation option for your operating system.
  • Restart your terminal after the installation finishes.
  • Run the version check again.

If the command still cannot run, help me get curl working in my terminal.

Confirm your coding agent and targets

Your coding agent needs the same repository as its working context. A harmless folder-path request proves that the agent can run a command there before you test network access.

  • Start your coding agent using the interface you normally use.
  • Open the repository you selected earlier in the agent.
  • Confirm that the agent shows the repository's top-level files.

The probe uses three destinations with different roles. This spread makes the agent's network boundary visible.

  • Use https://example.com as the host you expect to be allowed.
  • Use https://www.iana.org as the unrelated public host.
  • Use http://192.168.1.1 as the reachable local network address.

Before you ask the agent, what repository path do you expect it to report?

  • Type Print the current folder path. Do not change any files. into your agent's prompt box.
  • Submit the prompt.
  • Approve the read-only command if your agent requests permission.

You should see a folder path that points to the repository you selected. That response proves the agent can run commands with your repository as its working context.

Does the agent show a different folder?

  • Check that the repository is the active folder in your coding agent.
  • Repeat the folder-path request after switching the active folder.

If the agent cannot run the request, help me confirm my coding agent can run commands in the selected repository.

Your repository, normal terminal, coding agent, and three probe targets are ready. Next up, you will write the probe script and establish its normal-terminal baseline.

Create and Run the Network Probe

Your coding agent can only be compared with your normal terminal when both environments run the same requests. This baseline removes guesswork from every sandbox result that follows.

In this step, you will create one script that probes three targets in a fixed order. The script prints one result line for each target so later runs are easy to compare.

In this step, get ready to:
  • Create a reusable probe script for the three network targets.
  • Make the probe script executable.
  • Record a normal-terminal baseline where all three targets respond.
Define the probe sequence

The three requests need to stay in a fixed order. That order makes every later output difference easy to spot.

  • Open the repository you own in the code editor you use for agent work.
  • Select the new-file control in your editor's file panel.
  • Name the file probe-network.sh.
  • Paste the following code into probe-network.sh:
#!/bin/sh

# Store the targets in the order used for every comparison.
targets="https://example.com https://www.iana.org http://192.168.1.1"

# Request each target without printing its response body.
for target in $targets
do
  if curl --silent --output /dev/null "$target"
  then
    echo "SUCCESS: $target"
  else
    echo "FAILURE: $target"
  fi
done

How does the probe work?

  • The targets value keeps https://example.com first.
  • The for loop sends one curl request to each target.
  • The curl options hide the response body so the result stays readable.
  • The if branch prints SUCCESS after a completed request. A connection failure prints FAILURE.
  • Save probe-network.sh.
  • Confirm probe-network.sh is listed at the top level of your repository.

Don't see the saved script?

Check that the filename is exactly probe-network.sh. Make sure your editor did not add a hidden .txt extension.

Confirm the file sits inside the repository you own. The file panel should show it beside the repository's existing files.

Help me find or rename the probe script in my repository.

✔️ Awesome, I've got everything!

Good. Your saved probe-network.sh contains all three targets in the required order.

ⓧ I'd like to double check the full code

Compare your complete probe-network.sh file with this version:

#!/bin/sh

# Store the targets in the order used for every comparison.
targets="https://example.com https://www.iana.org http://192.168.1.1"

# Request each target without printing its response body.
for target in $targets
do
  if curl --silent --output /dev/null "$target"
  then
    echo "SUCCESS: $target"
  else
    echo "FAILURE: $target"
  fi
done
Run the terminal baseline

The normal terminal is your control environment. Its output shows what your machine can reach before the coding agent's network rules enter the picture.

  • Switch back to the normal terminal from earlier.
  • Enter your repository's full path here: path to your repository.

Before you run the probe, picture the three result lines you expect to see.

  • Execute this terminal sequence to produce your baseline:
cd "[[REPOSITORY_PATH="path to your repository"]]"
chmod u+x probe-network.sh
./probe-network.sh

What do these commands do?

  • The cd command moves the terminal into your repository.
  • The chmod command adds owner execute permission to probe-network.sh.
  • The ./probe-network.sh command runs the script from your repository.

You should see SUCCESS: https://example.com on the first line. You should see SUCCESS: https://www.iana.org on the second line.

You should see SUCCESS: http://192.168.1.1 on the third line. Each line confirms that curl received a response from that target.

That is the baseline locked in. Your normal terminal can reach every target in the probe.

Seeing a failure line?

Confirm your computer still has internet access if either public target fails. Run the probe again after the connection is restored.

Confirm your computer is connected to the same local network as http://192.168.1.1 if only the third target fails.

Help me diagnose a failed network probe result.

Your normal-terminal baseline is ready. Next, you will ask your coding agent to run the same probe inside its sandbox.

Compare the Agent Sandbox Results

Your normal-terminal run proved that your machine could reach all three probe targets. That result gives you a baseline for the coding agent test.

The coding agent executes repository commands inside a sandbox with separate network controls. Running the unchanged script there reveals whether those controls alter any result line.

In this step, get ready to:
  • Run probe-network.sh through the coding agent inside its sandbox.
  • Compare the sandbox output with the normal-terminal output.
  • Note every result line that differs.
Run the probe inside the agent sandbox

A fair comparison uses the same script in both environments. The three targets stay in the same order.

Some agents pause before executing repository commands. If yours does, it asks for permission to continue.

  • Switch back to the coding agent from earlier.
  • Ask the coding agent to confirm that its current workspace contains probe-network.sh.
  • Predict whether all three targets will respond inside the sandbox.
  • Ask the coding agent to run probe-network.sh inside its sandbox.
  • Grant permission for this run if the agent pauses for approval.
  • Wait for all three result lines.

You should see three sandbox result lines in the same target order: https://example.com, https://www.iana.org, then http://192.168.1.1.

Each line should show either a response or a failure for its target.

Missing one or more result lines?

  • Confirm that the agent's workspace is the repository containing probe-network.sh.
  • Ask the agent to return the complete script output if it only gives you a summary.

help me get the agent to run the complete probe.

Compare every result line

The normal-terminal output is your control result. Matching lines by target keeps the comparison accurate.

  • Switch back to the normal-terminal output from earlier.
  • Place the coding agent's sandbox output beside it.
  • Predict whether the sandbox output matches all three terminal result lines.
  • Compare the first result line for https://example.com.
  • Compare the second result line for https://www.iana.org.
  • Compare the third result line for http://192.168.1.1.
  • Enter every differing result line in the checkpoint below.
  • Enter All three lines matched if the outputs are identical.

You should now have two sets of three result lines.

Your notes should identify every changed line. If none changed, your notes should state that all three matched.

You have turned the sandbox test into evidence from your own machine. Next, you'll inspect the resolved sandbox configuration to explain those results.

Inspect the Sandbox Network Policy

Your earlier probe revealed which requests behaved differently inside the sandbox.

Those results show what happened. The resolved network policy reveals which controls produced that behavior.

In this step, get ready to:
  • Print the resolved sandbox configuration with your agent's inspection command.
  • Identify the hosts configured in the active policy.
  • Determine whether the agent currently enforces an allowlist.
Map the policy signals

A resolved configuration combines every settings source that affects the current session. This view gives you the policy the agent actually uses.

What does resolved mean?

Your agent may load settings from your repository. It may also load user settings or organization policy.

The resolved view combines those layers after precedence rules are applied. This prevents a lower-priority file from giving you a false picture of the active policy.

  • Use the inspection output to identify whether sandbox network access is enabled.
  • Locate every configured host in the resolved allowlist.
  • Find the control that determines how the agent handles unlisted hosts.
Inspect the resolved configuration

The inspection command depends on your coding agent. Choose the tab that matches the agent you used for the probe.

Claude Code

The Claude Code sandbox panel includes a Config tab with the resolved settings for your current session.

Before you open the panel, do you expect its host list to explain every difference from your probe?

  • Return to the Claude Code session that ran your probe.
  • Open the sandbox panel by entering this command:
/sandbox

What does this command show?

The /sandbox command opens the sandbox control panel. Its Config tab shows the resolved sandbox settings.

  • Select Config in the sandbox panel.
  • Identify the resolved value for sandbox.enabled.
  • Locate every entry under network.allowedDomains.
  • Identify the resolved value for network.strictAllowlist.

You should see whether the sandbox is enabled.

You should also see every allowed domain resolved for this session.

How to read the enforcement state

A true value for network.strictAllowlist means Claude Code denies hosts outside the allowlist instead of prompting.

An absent or false value means strict denial is not enabled in the resolved configuration.

Config tab missing?

  • Use the Dependencies tab to identify the missing sandbox component.
  • Install the named component with your system's supported package manager.
  • Restart Claude Code.
  • Run /sandbox again.

If the panel still does not show the resolved configuration, help me diagnose the missing Claude Code sandbox configuration.

Codex CLI

The Codex CLI provides configuration diagnostics that show layer precedence plus network policy requirements.

Before you print the diagnostics, do you expect the active policy to contain a host list?

  • Return to the Codex session that ran your probe.
  • Print the configuration diagnostics by entering this command:
/debug-config

How to read these diagnostics

The /debug-config command prints the order of configuration layers. It also identifies policy sources.

Command network access must be enabled through sandbox_workspace_write.network_access. Domain policy enforcement also requires features.network_proxy.enabled.

The features.network_proxy.domains map contains configured host rules. Managed network requirements appear under experimental_network when present.

  • Review the displayed configuration layer order.
  • Locate the value for sandbox_workspace_write.network_access.
  • Locate the value for features.network_proxy.enabled.
  • Identify every host rule under features.network_proxy.domains.
  • Check experimental_network for managed network constraints.

You should see the configuration sources that control your session.

An empty or absent domain map is still a concrete result.

When does Codex enforce the host list?

When command network access is enabled plus the network proxy is enabled, Codex applies the configured domain policy.

When command network access is enabled while the network proxy is disabled, sandboxed commands have unrestricted direct outbound access.

When command network access is disabled, sandboxed commands cannot use the network.

Inspection command unavailable?

  • Use the official Codex CLI update instructions if /debug-config is unavailable.
  • Restart your Codex session after the update.
  • Run /debug-config again.

If the diagnostics still omit the network controls, help me inspect the active Codex network policy.

You have replaced a guess with the agent's own configuration evidence. You can now connect the probe results to the controls that governed them.

  • Confirm that the inspection output identifies the active sandbox network state.
  • Confirm that the output identifies the configured host list.
  • Confirm that the output reveals whether unlisted hosts are currently denied.

Your resolved output should now show the active network state.

The same output should show the configured host policy.

Protect Private Configuration

Configuration output can feel sensitive, so keep your proof focused on the network controls.

  • Crop your screenshot to the network policy section.
  • Redact internal hostnames that are unrelated to the probe targets.
  • Hide any credential values before uploading.

Your active policy is now visible. Next, you will make the allowlist explicit so each denied request has a clear cause.

Enforce a Strict Allowlist

Your earlier inspection exposed the coding agent's resolved sandbox policy. You can now see whether an allowlist exists.

That output is only a snapshot. This step turns strict enforcement on so the sandbox must reject every host outside the list.

In this step, get ready to:
  • Create the agent-specific settings file for your repository.
  • Enable strict allowlist enforcement with only example.com listed.
  • Rerun the probe inside the sandbox to measure the enforced boundary.
Create the strict network policy

Strict enforcement changes the configured host list into a boundary. Any destination missing from that list should be rejected before the request leaves the sandbox.

  • Switch back to your repository in the coding agent from earlier.
  • Use the resolved configuration output from earlier to identify the project-level settings location for your agent.
  • Create the agent-specific settings file in that project-level location.

You should see the new settings file listed with probe-network.sh in your repository.

  • Set the exact strict-enforcement field named by your resolved configuration to its enabled value.
  • Save the agent-specific settings file.
  • Ask your coding agent to rerun the same sandbox inspection command from the previous step.

You should see strict allowlist enforcement reported as enabled in the resolved configuration.

  • Replace the configured host list with the single entry example.com.
  • Save the agent-specific settings file again.
  • Ask your coding agent to rerun its sandbox inspection command.

The resolved configuration should now report strict enforcement as enabled. Its configured host list should contain only example.com.

Why Start With One Host?

A one-host policy creates a clear baseline. Every successful request outside example.com would expose a gap in enforcement.

✔️ My resolved settings match

Your agent-specific settings file now enables strict network allowlist enforcement. The resolved host list contains only example.com.

ⓧ I'd like to double check the settings

Compare your resolved configuration against this final state:

  • Confirm strict network allowlist enforcement is enabled.
  • Confirm example.com is the only allowed host.
  • Confirm www.iana.org is absent from the allowed host list.
  • Confirm 192.168.1.1 is absent from the allowed host list.
Test the enforced boundary

A resolved configuration shows what the agent intends to enforce. Running the same probe proves what the sandbox actually permits.

Before you run the probe, which result lines do you expect to change under the one-host policy?

  • Ask your coding agent to rerun probe-network.sh inside the same sandbox as before.

You should see https://example.com succeed. The requests to https://www.iana.org and http://192.168.1.1 should be denied.

  • Check the denial for https://www.iana.org names www.iana.org as the blocked host.
  • Check the denial for http://192.168.1.1 names 192.168.1.1 as the blocked host.

That is the boundary doing real work. Your sandbox now permits the listed host while rejecting both unlisted destinations.

Probe Results Do Not Match?

  • Rerun the sandbox inspection command if all three targets remain allowed.
  • Confirm the resolved configuration reports strict enforcement as enabled.
  • Replace any full URL in the allowed host list with the single host entry example.com if the first target is denied.
  • Confirm the coding agent reran the probe inside the same sandbox that loaded your settings file.

If the results still differ, help me diagnose my sandbox allowlist.

Your strict boundary is now measurable. Next, you will add www.iana.org to the allowlist and watch exactly one result line change.

Allow the Second Public Host

Strict enforcement now gives you a clear baseline. Your coding agent's sandbox allows https://example.com.

The same probe denies https://www.iana.org plus http://192.168.1.1. Those two denials show that unlisted targets stay outside your network allowlist.

You will add only the second public host in this step. A single changed result will prove that the allowed-host list controls access.

In this step, get ready to:
  • Add www.iana.org to the existing strict network allowlist.
  • Rerun probe-network.sh inside the coding agent's sandbox.
  • Compare both sandbox results to confirm that exactly one line changes.
Add the second host to the allowlist

A controlled test changes one input at a time. Your only settings change is the addition of www.iana.org.

  • Switch back to the agent-specific settings file from earlier.
  • Find the allowed-host list that currently contains only example.com.
  • Add www.iana.org as a separate second entry. Match the list format used by example.com.
  • Confirm strict network allowlist enforcement remains enabled.
  • Save the agent-specific settings file.

✔️ My settings match

Your settings file keeps strict network allowlist enforcement enabled. Its allowed-host list contains exactly example.com plus www.iana.org.

ⓧ I'd like to double check the settings

The final settings state has two requirements.

  • Check that strict network allowlist enforcement is enabled.
  • Check that the allowed-host list contains exactly example.com plus www.iana.org.
Rerun the sandbox probe

The probe script remains unchanged. Running the same three targets isolates the effect of your one settings change.

Before you rerun the probe, which target result do you expect to change?

  • Return to the coding agent from earlier.
  • Ask the coding agent to rerun probe-network.sh inside its sandbox.

What should you see?

The https://example.com result remains allowed.

The https://www.iana.org result is now allowed. This is the only result that changes.

The http://192.168.1.1 result remains denied. Its message still names the blocked host.

Did the output change differently?

  • Return to the settings file if www.iana.org remains denied.
  • Check that www.iana.org is a separate host entry.
  • Check that strict enforcement remains enabled if the local address becomes allowed.

help me diagnose the unexpected sandbox probe result.

Prove the single-line change

A controlled experiment earns confidence when each output line is compared. The earlier sandbox result provides your baseline.

Before you compare the two runs, do you expect any result besides https://www.iana.org to change?

  • Place the earlier sandbox probe result beside the current result.
  • Compare the https://example.com line across both results.
  • Compare the https://www.iana.org line across both results.
  • Compare the http://192.168.1.1 line across both results.

The https://example.com line remains allowed.

The https://www.iana.org line changes from denied to allowed.

The http://192.168.1.1 line remains denied.

You have the clean proof. One explicit allowlist entry changed one public-host result.

Your strict allowlist now permits both public hosts while keeping the local address blocked. Next, you will capture these results in a table inside your repository.

Record the Network Results

Your network allowlist now admits both public hosts. The private address stays denied. Those results prove that the policy changes what your coding agent can reach.

A results file turns the tests into evidence you can keep with the repository. It also records your policy decision before the terminal output disappears.

In this step, get ready to:
  • Consolidate the four probe runs into a results table.
  • Record whether the private-network address was blocked separately.
  • Document your strict enforcement decision with the reason for allowing www.iana.org.
Build the results table

A Markdown table places each target beside every probe run. This makes the effect of each policy change visible in one row.

  • Review your noted initial sandbox result for https://example.com. Enter it here: allowed or denied from your initial example.com sandbox run.
  • Review your noted initial sandbox result for https://www.iana.org. Enter it here: allowed or denied from your initial www.iana.org sandbox run.
  • Review your noted initial sandbox result for http://192.168.1.1. Enter it here: allowed or denied from your initial private-address sandbox run.
  • Create network-results.md inside your repository by adding this table:
# Network Probe Results

| Target | Normal terminal | Initial sandbox | Strict allowlist | Two-host allowlist |
| --- | --- | --- | --- | --- |
| `https://example.com` | Allowed | [[EXAMPLE_INITIAL_RESULT="allowed or denied from your initial example.com sandbox run"]] | Allowed | Allowed |
| `https://www.iana.org` | Allowed | [[IANA_INITIAL_RESULT="allowed or denied from your initial www.iana.org sandbox run"]] | Denied | Allowed |
| `http://192.168.1.1` | Allowed | [[LOCAL_INITIAL_RESULT="allowed or denied from your initial private-address sandbox run"]] | Denied | Denied |

What does this table prove?

  • The Normal terminal column preserves the baseline from outside the sandbox.
  • The Initial sandbox column captures your agent's original behavior without assuming that every agent has the same default.
  • The final two columns isolate the allowlist change. Only the result for https://www.iana.org flips.
  • Save network-results.md.
  • Check your editor's file sidebar for network-results.md.

You should see network-results.md stored in the same repository as probe-network.sh.

Does the table look misaligned?

Check that every table row contains the same number of pipe characters. Confirm that the separator row remains directly below the column headings.

Ask for help with the table formatting: help me fix my Markdown results table

Document the policy decision

The table captures observed behavior. A short note connects that evidence to the resolved configuration and your final enforcement choice.

  • Record whether the inspection output confirmed separate private-range blocking: yes, no, or not confirmed by inspection.
  • Choose your enforcement decision: keep strict enforcement enabled or change it.
  • Summarize the reason for that decision: why this policy fits your work.
  • Explain the purpose of allowing www.iana.org: why your probe or workflow needs www.iana.org.
  • Add the policy notes below the table by pasting this content:
## Private Network Note

Separate private-range blocking: [[PRIVATE_RANGE_STATUS="yes, no, or not confirmed by inspection"]].

Evidence: `http://192.168.1.1` remained denied after both public hosts were allowlisted.

## Enforcement Decision

Decision: [[STRICT_ENFORCEMENT_DECISION="keep strict enforcement enabled or change it"]].

Reason: [[ENFORCEMENT_REASON="why this policy fits your work"]].

Why `www.iana.org` is allowed: [[IANA_ALLOW_REASON="why your probe or workflow needs www.iana.org"]].

Why record both evidence and policy?

The private-network note separates the behavior you observed from the configuration detail reported by the inspection command. This prevents the denied request from carrying more meaning than the evidence supports.

The enforcement section captures your policy choice. The reason for allowing www.iana.org gives future readers the context behind that exception.

  • Save network-results.md.
  • Scroll to the bottom of network-results.md.

You should see the private-network note followed by your enforcement decision. The final line should explain why www.iana.org belongs on the allowlist.

Missing the policy notes?

Make sure you added the notes below the final table row in network-results.md. Check that the file has been saved after your latest edit.

Ask for help checking the file structure: help me place the policy notes in my results file

✔️ Awesome, I've got everything!

Your results table and policy notes are saved in network-results.md.

ⓧ I'd like to double check the full code

Compare your complete network-results.md file with this reference:

# Network Probe Results

| Target | Normal terminal | Initial sandbox | Strict allowlist | Two-host allowlist |
| --- | --- | --- | --- | --- |
| `https://example.com` | Allowed | [[EXAMPLE_INITIAL_RESULT="allowed or denied from your initial example.com sandbox run"]] | Allowed | Allowed |
| `https://www.iana.org` | Allowed | [[IANA_INITIAL_RESULT="allowed or denied from your initial www.iana.org sandbox run"]] | Denied | Allowed |
| `http://192.168.1.1` | Allowed | [[LOCAL_INITIAL_RESULT="allowed or denied from your initial private-address sandbox run"]] | Denied | Denied |

## Private Network Note

Separate private-range blocking: [[PRIVATE_RANGE_STATUS="yes, no, or not confirmed by inspection"]].

Evidence: `http://192.168.1.1` remained denied after both public hosts were allowlisted.

## Enforcement Decision

Decision: [[STRICT_ENFORCEMENT_DECISION="keep strict enforcement enabled or change it"]].

Reason: [[ENFORCEMENT_REASON="why this policy fits your work"]].

Why `www.iana.org` is allowed: [[IANA_ALLOW_REASON="why your probe or workflow needs www.iana.org"]].

What should match?

Your initial sandbox cells should contain the outcomes you noted earlier. The remaining columns should match the observed allowlist runs exactly.

Verify the evidence record

Before you compare the final columns, which target do you expect to be the only one with a changed result?

  • Compare the Strict allowlist column with the Two-host allowlist column.
  • Read the Private Network Note to confirm that it states what the inspection output revealed.
  • Read the Enforcement Decision to confirm that it records your policy choice.
  • Check the final line for the reason www.iana.org was allowed.

You should see exactly one change between the final two columns. The https://www.iana.org result changes from Denied to Allowed.

The https://example.com result remains allowed. The http://192.168.1.1 result remains denied.

You have turned a sequence of terminal tests into a durable network-access record. Your repository now shows what the agent could reach and why the final allowlist has two public hosts.

Secret mission

Run a Least-Privilege Regression Test

Temporarily remove www.iana.org from your strict allowlist. Prove that one public-host result changes. Restore the original two-host baseline.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep the project evidence, pause your work, or remove the project-specific files and policy changes. This local project creates no ongoing infrastructure costs.

Resources you used:

  • The executable network probe stored in probe-network.sh.
  • The before-and-after evidence stored in network-results.md.
  • The project-specific strict network allowlist configuration stored in the agent-specific settings file. It allows example.com and www.iana.org.

Keep everything running

No action is needed. Choose this option if you want the probe evidence and strict policy ready for future checks.

  • Keep probe-network.sh in your repository so you can test the same three targets again.
  • Keep network-results.md as a record of the access differences you measured.
  • Leave strict enforcement enabled with example.com and www.iana.org on the allowlist.
  • Use the results table as a baseline when your coding agent or its network settings change.

Pause - I'll come back to this later

This project leaves no cloud service or local server running. Pausing means ending the current agent session while preserving the repository.

  • End the current coding-agent sandbox session using the same exit control you normally use.
  • Keep the repository unchanged so the probe script and results remain available.
  • Confirm that network-results.md records your decision to retain strict enforcement.

Your files and allowlist remain ready for the next network-access check.

Delete - I don't want to use this again

Deleting the evidence can feel final. This cleanup leaves your coding agent and curl installed.

The network policy changes affect your agent after the project ends. Remove those changes before deleting the evidence files.

  • Return to the agent-specific settings file in the repository from earlier.
  • Remove the strict network allowlist enforcement setting added during this project.
  • Remove the example.com entry from the allowed host list.
  • Remove the www.iana.org entry from the allowed host list.
  • Save the agent-specific settings file.
  • Check the agent's resolved sandbox configuration with the same inspection workflow from earlier.

You should no longer see the strict enforcement setting or host entries added by this project. That confirms the project-specific network policy is gone.

The script and table are the two standalone evidence files. Use the instructions for your operating system to remove them without deleting the rest of your repository.

macOS

  • Use Finder to return to the repository you used for this project.
  • Move probe-network.sh to Trash.
  • Move network-results.md to Trash.
  • Empty Trash to remove both files permanently.

You should no longer see probe-network.sh or network-results.md in the repository.

Windows

  • Use File Explorer to return to the repository you used for this project.
  • Move probe-network.sh to the Recycle Bin.
  • Move network-results.md to the Recycle Bin.
  • Empty the Recycle Bin to remove both files permanently.

You should no longer see probe-network.sh or network-results.md in the repository.

That clears the project's evidence while preserving the rest of your repository. Your coding agent and curl remain available for other work.

Nice Work!

Nice Work!

You did it! You turned your coding agent's network access into evidence that you can rerun and audit.

What you can now do:

  • Use an executable probe script to test three network targets. Compare probe-network.sh results across a normal terminal versus the agent's sandbox.
  • Inspect the agent's resolved network configuration. Identify which hosts are listed. Confirm whether allowlist enforcement is active.
  • Prove that a strict allowlist controls public-host access by watching one probe line flip from denied to allowed. Confirm that the private-network target stays denied. Preserve every outcome in network-results.md.
  • Secret Mission: Complete the optional challenge to push your network-policy testing skills further.

Ready to quiz yourself?