Unable to run Go tests due to highly restrictive sandbox

What version of Codex is running?

codex-cli 0.42.0

Which model were you using?

gpt-5-codex-high

What platform is your computer?

macOS 15.5

What steps can reproduce the bug?

Summary from the model itself on why it fails to run Go tooling:

At this point the Go toolchain itself is fine—our failures come entirely from tests that rely on OS sockets (Postgres, Redis, httptest.NewServer). The
Seatbelt profile applied to Go binaries denies both network-client and network-server, so anything that dials 127.0.0.1 or binds even an ephemeral port
dies.

Recommendation

Break the dependency on real sockets for the default test run, and quarantine the true integration cases behind an opt-in flag you can execute outside
the sandbox.

• Database: swap the Postgres-backed fixtures to an in-memory alternative so we only exercise SQL semantics. gorm already supports SQLite; we can

introduce a NewTestDatastore helper that configures gorm.Open(sqlite, "file::memory:?cache=shared"), seeds schema with our migrations, and returns the
handles/transaction wrappers existing tests expect. Where Postgres-specific behavior is needed, create a separate _integration suite (or reuse current
tests but guard them with //go:build integration) so they’re skipped in the sandbox.

• Redis / SSE: the current tests spin up real redis-compatible listeners (miniredis) and SSE managers that bind ports. Introduce an interface-friendly

abstraction—e.g., wrap redis usage behind RedisBroker and supply an in-memory implementation built on top of Go maps + channels for tests. SSE tests can
be rewritten to exercise the manager API directly (using httptest.NewRecorder with the handler) rather than wiring a real server.

• HTTP clients/servers: replace httptest.NewServer usage with direct handler invocation (httptest.NewRecorder, plain request objects) or a custom listener

that operates entirely in-memory (e.g., net.Pipe). For outbound HTTP calls, substitute transport stubs (http.Client{Transport: roundTripperMock}) instead
of real sockets.

• Segregate real-integration coverage: the handful of tests that must interact with actual Postgres/Redis/HTTP can be gated under a integration build tag

or _integration_test.go files. They’ll stay runnable on your laptop or CI, while the default go test ./... covers all sandbox-safe units.

Once we restructure the suites accordingly, I’ll be able to run go test inside the sandbox without touching the network profile. If you prefer a staged
approach, we can start by converting the highest-churn suites (handlers, models) to the SQLite/stubbed Redis strategy and flip the remaining Postgres-
heavy tests behind an integration tag for now.

What is the expected behavior?

_No response_

What do you see instead?

_No response_

Additional information

_No response_

  Tests: dotnet test xxx.csproj (couldn’t complete—sandbox blocks the vstest socket listener with
  System.Net.Sockets.SocketException: Permission denied; please rerun outside the restricted environment to confirm the suite).