Restrict agent internet access on Refactoring (RF) tasks

[mohit-raghavendra]

Mirrors the Test Writing lockdown, for the Refactoring (RF) tasks.

• Adds a network allowlist (package registries + language toolchains) to the agent phase of all 70 RF task.toml files, so reference solutions can't be looked up online.
• Bakes Go module/toolchain dependencies into the Go task images so tests still build offline under the allowlist.
• Allows git-over-https in the renovate images so the codex agent installer can bootstrap Node.
• Updates the opus-4.6 run config to restrict internet access and adds an opus-4.8 run config.

Greptile Summary

This PR restricts agent-phase internet access for all 70 RF (Refactoring) tasks, mirroring the lockdown previously applied to Test Writing tasks. The [agent] section of every task.toml gains a network_mode = \"allowlist\" block covering common package registries (PyPI, Debian/Ubuntu/Alpine, Go, npm/yarn), while the [environment] build phase retains allow_internet = true.

• Go task images (trufflehog, grafana/k6, grafana/grafana-Go): each gets a new Dockerfile layer that pre-bakes module dependencies and the resolved toolchain via GOTOOLCHAIN=auto, then sets GOPROXY=off, GOSUMDB=off, and GOTOOLCHAIN=local so agent-phase builds work fully offline.
• Renovate images: existing Dockerfiles gain GIT_ALLOW_PROTOCOL=file:git:https:ssh so the harbor/codex Node bootstrapper (nvm, which clones over HTTPS) can function under the locked-down image.
• Run configs: opus-4p6 is updated with --ak disallowed_tools=WebSearch,WebFetch and --allow-agent-host, concurrency bumped from 16→24; a new opus-4p8-xhigh config is added with the same restrictions plus --max-retries 3.

Confidence Score: 4/5

Safe to merge; the lockdown is consistent, mirrors a proven pattern from the TW tasks, and the two flagged items are minor hardening opportunities with no correctness impact.

The change is large in file count but highly repetitive and mechanical—the same allowlist block and the same Dockerfile layer are stamped across 70 tasks. The Go pre-baking logic is sound: toolchain download happens before compilation under GOTOOLCHAIN=auto, so || true only masks post-download build errors. The two concerns—overly broad GIT_ALLOW_PROTOCOL and silent stderr suppression in the vendored-build step—do not affect correctness under normal conditions, but they reduce observability and marginally widen the protocol surface in the renovate images.

The three renovate Dockerfiles (afc2, afc3, afc4) deserve a second look on the GIT_ALLOW_PROTOCOL value. The shared Go Dockerfile pattern used across all ~25 Go tasks is worth confirming in one real image build to verify the toolchain copy lands at /usr/local/go correctly.

Important Files Changed

Filename	Overview
data/rf/task-69391d8d1ce51c407be1e531/environment/Dockerfile	Adds Go module/toolchain pre-baking layer; representative of all ~25 Go task Dockerfiles; correctly silences build errors with `
data/rf/task-69d196f015a150488265afc2/environment/Dockerfile	Adds GIT_ALLOW_PROTOCOL=file:git:https:ssh to three renovate task images; includes the git: (unauthenticated) protocol alongside the https: actually needed by nvm.
data/rf/task-69391d8d1ce51c407be1e531/task.toml	Representative Go task.toml: removes static docker_image reference (replaced by new Dockerfile), adds identical 15-entry agent allowlist. Pattern is consistent across all 70 changed task.toml files.
run_config/rf/opus-4p6_claude-code.sh	Adds HARBOR_BIN variable indirection, HARBOR_AGENT_ALLOWED_HOST required env guard, disallowed_tools flag, and --allow-agent-host; bumps concurrency from -n 16 to -n 24.
run_config/rf/opus-4p8-xhigh_claude-code.sh	New run config for opus-4-8 with xhigh reasoning, n=32 concurrency, --max-retries 3, and the same internet-restriction flags as the updated opus-4p6 config.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[RF task.toml] --> B{Language?}
    B -->|Go - trufflehog / k6 / grafana-Go| C[New Dockerfile layer]
    B -->|Python / TypeScript / C++| D[Keep existing docker_image]
    B -->|renovatebot/renovate| E[Existing Dockerfile + GIT_ALLOW_PROTOCOL fix]

    C --> C1["GOTOOLCHAIN=auto go build -mod=vendor ./...\n(vendored) OR go mod download all\n(non-vendored)"]
    C1 --> C2[Copy resolved toolchain to /usr/local/go]
    C2 --> C3["ENV: GOPROXY=off, GOSUMDB=off, GOTOOLCHAIN=local"]

    D --> F[agent phase]
    C3 --> F
    E --> F

    F --> G["network_mode = allowlist\nallowed_hosts: PyPI, Debian/Ubuntu/Alpine,\ngo.dev, dl.google.com, npm/yarn, nodejs.org"]
    G --> H[Agent runs offline-capable build]

    I[run_config scripts] --> J["--ak disallowed_tools=WebSearch,WebFetch\n--allow-agent-host HARBOR_AGENT_ALLOWED_HOST"]
    J --> H

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
data/rf/task-69d196f015a150488265afc2/environment/Dockerfile:4
**`git:` protocol unnecessarily included in GIT_ALLOW_PROTOCOL**

The comment says this unblocks the harbor codex installer, which bootstraps Node via nvm over HTTPS. nvm only needs `https:` (and `ssh:` for SSH remotes); the `git:` entry enables the unauthenticated `git://` protocol, which is broader than necessary. While the agent-phase network allowlist limits which hosts are reachable, dropping `git:` would narrow the attack surface with no functional cost. The same pattern appears in the other two renovate Dockerfiles (`afc3`, `afc4`). Consider using `GIT_ALLOW_PROTOCOL=file:https:ssh` instead.

### Issue 2 of 2
data/rf/task-69391d8d1ce51c407be1e531/environment/Dockerfile:10-15
**Silent failure masks toolchain-download errors for vendored repos**

`2>/dev/null || true` ensures the Dockerfile layer never fails on compilation errors (intentional—the build may not compile cleanly), but it also hides toolchain-download failures. If `GOTOOLCHAIN=auto` fails to fetch the required toolchain (e.g., a transient network issue during image build), the `TC` glob finds nothing, the `if [ -n "$TC" ]` block is skipped, and the original `/usr/local/go` is kept intact. With `GOTOOLCHAIN=local` baked in by the subsequent `ENV`, the agent will then use the original (potentially incompatible) toolchain version and produce opaque build failures at run time. At minimum, keeping toolchain-download errors on stderr (omitting `2>/dev/null`) would make image-build logs actionable. The same pattern is used across all ~25 Go task Dockerfiles.

_{Reviews (1): Last reviewed commit: "Restrict agent internet access on Refact..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[greptile-apps]

git: protocol unnecessarily included in GIT_ALLOW_PROTOCOL

The comment says this unblocks the harbor codex installer, which bootstraps Node via nvm over HTTPS. nvm only needs https: (and ssh: for SSH remotes); the git: entry enables the unauthenticated git:// protocol, which is broader than necessary. While the agent-phase network allowlist limits which hosts are reachable, dropping git: would narrow the attack surface with no functional cost. The same pattern appears in the other two renovate Dockerfiles (afc3, afc4). Consider using GIT_ALLOW_PROTOCOL=file:https:ssh instead.

Prompt To Fix With AI

This is a comment left during a code review.
Path: data/rf/task-69d196f015a150488265afc2/environment/Dockerfile
Line: 4

Comment:
**`git:` protocol unnecessarily included in GIT_ALLOW_PROTOCOL**

The comment says this unblocks the harbor codex installer, which bootstraps Node via nvm over HTTPS. nvm only needs `https:` (and `ssh:` for SSH remotes); the `git:` entry enables the unauthenticated `git://` protocol, which is broader than necessary. While the agent-phase network allowlist limits which hosts are reachable, dropping `git:` would narrow the attack surface with no functional cost. The same pattern appears in the other two renovate Dockerfiles (`afc3`, `afc4`). Consider using `GIT_ALLOW_PROTOCOL=file:https:ssh` instead.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Silent failure masks toolchain-download errors for vendored repos

2>/dev/null || true ensures the Dockerfile layer never fails on compilation errors (intentional—the build may not compile cleanly), but it also hides toolchain-download failures. If GOTOOLCHAIN=auto fails to fetch the required toolchain (e.g., a transient network issue during image build), the TC glob finds nothing, the if [ -n "$TC" ] block is skipped, and the original /usr/local/go is kept intact. With GOTOOLCHAIN=local baked in by the subsequent ENV, the agent will then use the original (potentially incompatible) toolchain version and produce opaque build failures at run time. At minimum, keeping toolchain-download errors on stderr (omitting 2>/dev/null) would make image-build logs actionable. The same pattern is used across all ~25 Go task Dockerfiles.

Prompt To Fix With AI

This is a comment left during a code review.
Path: data/rf/task-69391d8d1ce51c407be1e531/environment/Dockerfile
Line: 10-15

Comment:
**Silent failure masks toolchain-download errors for vendored repos**

`2>/dev/null || true` ensures the Dockerfile layer never fails on compilation errors (intentional—the build may not compile cleanly), but it also hides toolchain-download failures. If `GOTOOLCHAIN=auto` fails to fetch the required toolchain (e.g., a transient network issue during image build), the `TC` glob finds nothing, the `if [ -n "$TC" ]` block is skipped, and the original `/usr/local/go` is kept intact. With `GOTOOLCHAIN=local` baked in by the subsequent `ENV`, the agent will then use the original (potentially incompatible) toolchain version and produce opaque build failures at run time. At minimum, keeping toolchain-download errors on stderr (omitting `2>/dev/null`) would make image-build logs actionable. The same pattern is used across all ~25 Go task Dockerfiles.

How can I resolve this? If you propose a fix, please make it concise.