Kotlin og Gradle i sandkassen

Oppsett som dekker de fleste

Et vanlig Kotlin-prosjekt trenger to innstillinger. Gradle starter en daemon som snakker med bygget over en tilfeldig port på localhost, og cplt stenger localhost (også med --no-daemon). MockK, Mockito og ByteBuddy kobler seg til JVM-en mens testene kjører, og den socketen stenger cplt på macOS.

cplt config set sandbox.allow_localhost_any true
cplt config set sandbox.allow_jvm_attach true

Med allow_localhost_any når agenten alle tjenester som lytter på localhost, også en lokal database. På Linux koster den mer: kjernen der kan ikke skille localhost fra andre verter, så cplt slår av portfiltreringen for utgående TCP helt, og bare proxyen begrenser hvor agenten kan koble seg til. allow_jvm_attach åpner bare socketene /tmp/.java_pid<PID>, ingen andre.

Gjelder det ett prosjekt, legg innstillingene i repoet, så får hele teamet dem:

cplt config set --repo sandbox.allow_localhost_any true
cplt config set --repo sandbox.allow_jvm_attach true
git add .cplt.toml && git commit -m "chore: cplt-oppsett for Gradle"
cplt trust accept --all

Hvordan .cplt.toml og godkjenningen virker, står i Sett opp cplt i et repo. cplt init foreslår allow_jvm_attach for et Gradle-bygg, men ikke allow_localhost_any. På Linux trenger du ikke allow_jvm_attach, for der stenger ikke cplt socketen.

Wrapperen og en liste over tillatte verter

I standardoppsettet stopper cplt bare kjente skadelige verter og verter med private adresser. Da laster ./gradlew ned Gradle og avhengigheter som vanlig.

Har du slått på en liste over tillatte verter, med --preset strict, proxy.default_allowlist eller proxy.allowed_domains, slipper cplt bare gjennom det som står på lista. Med proxy.default_allowlist er de vanlige pakkeregistrene med:

• repo.maven.apache.org (Maven Central)
• plugins.gradle.org og plugins-artifacts.gradle.org (Gradle-plugins)
• packages.confluent.io og jitpack.io

Selve Gradle-distribusjonen som wrapperen laster ned, er ikke med. Den kommer fra services.gradle.org, som sender videre til github.com og release-assets.githubusercontent.com. Uten disse stopper ./gradlew før bygget starter, og proxyloggen viser BLOCKED-ALLOWLIST. Legg til vertene:

cplt config set allow.domains services.gradle.org
cplt config set allow.domains github.com
cplt config set allow.domains release-assets.githubusercontent.com

Copilot har github.com på lista fra før, så med Copilot kan du hoppe over den linja. allow.domains legger verter til en liste som allerede er slått på. Den slår ikke på lista.

Sjekk en vert uten å kjøre bygget:

cplt check net services.gradle.org

Pakker fra GitHub Packages

Mange navikt-biblioteker ligger i GitHub Packages. Speilet er den enkleste måten å hente dem på i sandkassen.

Navs speil, uten token

github-package-registry-mirror.gc.nav.no er et åpent speil av de offentlige pakkene i GitHub Packages. Det krever ingen token, så agenten trenger ikke tilgang til noen hemmeligheter:

repositories {
    mavenCentral()
    maven("https://github-package-registry-mirror.gc.nav.no/cached/maven-release")
}

Speilet står ikke på cplts liste over tillatte verter. Bruker du en slik liste, legg det til:

cplt config set allow.domains github-package-registry-mirror.gc.nav.no

Token i ~/.gradle/gradle.properties

maven.pkg.github.com krever token. På macOS stenger cplt ~/.gradle/gradle.properties fordi fila ofte har tokens i seg, og finnes fila, stopper hvert Gradle-bygg i sandkassen med Error when loading properties file. Det tryggeste er å flytte det du trenger over til speilet og ta tokenet ut av fila. Ellers gir du agenten lesetilgang til fila, og dermed alle tokenene i den:

cplt config set allow.read ~/.gradle/gradle.properties

Trenger du også ~/.npmrc og ~/.m2/settings.xml, se Pakker fra GitHub Packages i oppsettguiden.

Leser bygget tokenet fra GITHUB_TOKEN, kommer det an på agenten. Copilot får GITHUB_TOKEN, GH_TOKEN og COPILOT_GITHUB_TOKEN slik de står i skallet ditt, fordi Copilot trenger et GitHub-token. OpenCode og de andre agentene får dem ikke, og det gjør heller ikke cplt exec. Der sender --pass-env GITHUB_TOKEN den med, men da har agenten tokenet ditt.

Under en liste over tillatte verter når Copilot maven.pkg.github.com, fordi lista har med github.com og alle undervertene. Får du Received status code 401 from server: Unauthorized, har forespørselen kommet fram. Da er det tokenet som mangler, ikke nettverket.

Interne Nav-verter

cplt stopper forbindelser til verter som peker til en privat IP-adresse. Det gjelder også Gradle, fordi cplt sender JVM-ens nettverkstrafikk gjennom proxyen sin. Når en slik vert er et Maven-repo, stopper bygget med Private target blocked by cplt. Det kan gjelde repo.adeo.no på Nav-nettet og verter under intern.nav.no. Åpne vertene med navn:

cplt config set proxy.allow_private_domains repo.adeo.no
cplt config set proxy.allow_private_domains intern.nav.no

Ett navn dekker alle undervertene. For ett prosjekt kan du bruke cplt config set --repo proxy.allow_private_domains … og godkjenne med cplt trust accept, slik pensjonsbrev gjør. For én økt holder flagget --allow-private-domain repo.adeo.no.

Står repoet oppført med en IP-adresse i stedet for et navn, for eksempel https://10.20.30.40/repository/, kan ingen innstilling åpne det. Bruk vertsnavnet i byggefila.

JDK-er som Gradle laster ned

Med jvmToolchain(…) og foojay-pluginen laster Gradle ned JDK-en prosjektet ber om, til ~/.gradle/jdks. På macOS kan agenten kjøre JDK-ene som ligger der, men ikke skrive nye dit, så en JDK som mangler, kan ikke lastes ned inne i cplt. På Linux er mappa skrivbar. Under en liste over tillatte verter må api.foojay.io og vertene JDK-en hentes fra, stå på lista. For Temurin er det de samme som for wrapperen.

Kjør bygget én gang utenfor cplt, så ligger JDK-en klar. Etterpå kan du se hvilke JDK-er Gradle finner:

./gradlew javaToolchains

Vil du at bygget skal feile med en gang i stedet for å prøve å laste ned, sett dette i prosjektets gradle.properties:

org.gradle.java.installations.auto-download=false

Feilmeldingen fra foojay ser ut som et nettverksproblem. Se Unable to download toolchain.

Testcontainers og Docker

cplt stenger Docker, fordi tilgang til Docker i praksis er root på maskinen (se Docker i oppsettguiden). Testcontainers feiler derfor i cplt uten videre. Du har tre muligheter, fra tryggest til minst trygg:

• Kjør testene som trenger containere, utenfor cplt. La agenten kjøre resten.
• Start containerne selv, utenfor cplt, og åpne portene. Det passer for en database eller Kafka fra docker compose, men ikke for Testcontainers, som starter containerne selv.
• Gi agenten Docker. Da virker Testcontainers, også med colima. Agenten kan da gjøre alt Docker kan, og lese ~/.docker med registerinnloggingene dine. Bruk det bare i et repo du stoler på, og helst bare for én økt.

En database på port 5432, startet utenfor cplt:

cplt config set allow.localhost 5432

Slik gir du agenten Docker for én økt eller fast. Testcontainers kobler seg til containerne over tilfeldige porter på localhost, så slå på allow_localhost_any også:

cplt --allow-docker
cplt config set sandbox.allow_docker true --force

Med colima må TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE=/var/run/docker.sock være satt, som utenfor cplt. cplt sender DOCKER_HOST og TESTCONTAINERS_* videre til agenten.

Når bygget feiler

Slå på loggen over blokkerte forbindelser, og kjør bygget i sandkassen selv:

cplt config set proxy.log_level blocked
cplt exec -- ./gradlew build

Linjer med [proxy] og BLOCKED viser hvilken vert som ble stoppet og hvorfor. Blokkeringer av filer og localhost står ikke der, se Filer, programmer og localhost. Feilmeldingene fra Gradle og JVM står i Feil i sandkassen. Mer om hvorfor står i known-impacts.md (engelsk).

Kommandoene på denne siden er testet med cplt fra 29. september 2026 på macOS, med et lite Kotlin-prosjekt, Gradle 9.7.0 og 9.8.0 og colima.