fix: allow resume of stopped coderunner container

[mvanhorn]

Summary

install.sh always launched the sandbox with container run --rm, which destroys the container on container stop. There was no documented or supported path to stop the sandbox and resume it later: the next ./install.sh ran container image pull and container run --rm again, starting from a fresh state every time.

Two changes:

1. Try container start coderunner at the top of install.sh. If the container exists, resume it and exit early. If it doesn't, fall through to the pull + run path.
2. Drop --rm from container run so the sandbox survives a container stop.

README adds a ## Stop and resume section documenting both paths (resume the same sandbox, or container delete + re-install for a clean start).

Why this matters

#4 (filed by @mkagenius in July 2025) asks for the ability to resume coderunner after stopping it. The current install script makes that impossible by design (--rm). Keeping uploads, kernels, and pip-installed packages across restarts is a reasonable workflow for an MCP-served sandbox; the alternative is reinstalling deps every restart, which defeats the persistent-assets dir the installer already creates at ~/.coderunner/assets.

Closes #4

[gemini-code-assist]

Code Review

This pull request introduces container persistence by removing the --rm flag from the container run command and adding logic to resume existing containers in install.sh. The README.md has been updated with instructions for stopping and resuming the sandbox. A review comment suggests updating a log message in the installation script to accurately reflect the volume mounts being used, which would improve clarity for users debugging their setup.

[gemini-code-assist]

The echo message is misleading as it omits the --volume flags that are actually being used in the subsequent container run command. Since persistence is a key feature of this PR, showing the volume mounts in the log (or using a more generic message) would improve clarity for users debugging their setup.

Suggested change

	echo "Running: container run --name coderunner --detach --cpus 8 --memory 4g instavm/coderunner"
	echo "Running: container run --volume \"$ASSETS_SRC/skills/user:/app/uploads/skills/user\" --volume \"$ASSETS_SRC/outputs:/app/uploads/outputs\" --name coderunner --detach --cpus 8 --memory 4g instavm/coderunner"

[mvanhorn]

Fixed in 8462521 — the startup echo now includes both --volume flags so it matches the actual container run invocation. Thanks for the catch.

[mkagenius]

Thank you! @mvanhorn

[mvanhorn]

Thanks for landing this, @mkagenius. Resume-on-stopped was a niggle worth fixing.

[mvanhorn]

@mkagenius appreciate the container-resume fix. Dropping --rm so the sandbox survives container stop is a small change with a big quality-of-life payoff; resuming is the obvious user expectation.