skz-sloptrap/AGENTS.md

skz-sloptrap

This workspace is the source code of sloptrap, eg. your own runtime. Your author, 'sk4nz', has ran the command sloptrap path/to/skz-sloptrap and you are living in your own reflection.

Recursive slopsloptrap

sloptrap can recurse.

If you need to prove it, spawn a child from this repo with sloptrap:

./sloptrap /workspace ...

This starts a child slopsloptrap. Use the child normally, as the end-user would.

Keep Memory

Future sloptrap instances should add short, useful, durable notes they learn during their session to this file.

Only add high-signal information that is likely to help later runs. Keep additions brief. Do not remove existing instructions unless they are outdated or wrong.

---

Session Memory

• When you make changes that affect how the runtime behaves and cannot test it with recursion, you can ask sk4nz to restart you.
• If recursion is blocked by the current session state and a restart is required, give sk4nz an exact prompt to paste into the next restarted session so it can continue from the current checkpoint.
• Useful checks in the skz-sloptrap repo: shellcheck sloptrap bash tests/run_tests.sh (you can also run them separately)
• Recursive nested-podman inside an already user-namespaced sloptrap needs subuid/subgid ranges derived from /proc/self/uid_map and /proc/self/gid_map; hardcoding 100000:65536 breaks newuidmap.
• When running tests from inside sloptrap, inherited CODEX_HOME=/codex plus SLOPTRAP_PREFER_CODEX_HOME=1 can leak into host-style child launches; ignore that preference when HOME has been redirected elsewhere and the runtime hints still point into the inherited /codex tree.
• For real recursive ./sloptrap launches, correct /proc/self/uid_map alone is not enough: if the current session still has stale read-only /etc/subuid and /etc/subgid mounts (for example sk4nz:100000:65536), the first nested podman launch still fails before child startup.
• Forcing SLOPTRAP_CONTAINER_ENGINE=sloppodman inside sloptrap also needs TMPDIR under /workspace; otherwise its build-context path guard rejects the staged Dockerfile under /tmp before you reach the real subuid/subgid problem.
• If a restarted session still inherits stale read-only /etc/subuid and /etc/subgid tmpfs mounts, an unprivileged agent cannot repair them in-place (umount says must be superuser to unmount); both podman and sloppodman stay blocked until the session starts without those mounts.
• Outer sloptrap launches no longer need /etc/subuid or /etc/subgid bind mounts: nested-podman now disables read-only rootfs and the container entrypoint synthesizes container-local subid files from /proc/self/{uid,gid}_map before dropping privileges.
• With stale subid mounts gone, recursive ./sloptrap /workspace can still fail earlier during the inner image build: crun tries to open /proc/sys/net/ipv4/ping_group_range and gets Read-only file system while creating the build container.
• In a fragile nested-podman session, podman system migrate can make things worse: a state that still answered podman info fell back to repeated newuidmap ... write to uid_map failed: Operation not permitted failures afterward.