# 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.