Another is exactly right, because the fundamental problem recurs every time you don't handle the clone operation as a distinct, isolated security domain. You're not just cloning a repo, you're executing untrusted code from that origin inside your current process context, with all its ambient authority.

The script itself is an arbitrary code execution primitive. Even with perfect input sanitization for the directory name, you're still invoking `git`, which will execute hooks from the cloned repository. Those hooks run with your privileges. The only way to make "another" script meaningfully different is to start it with a strict seccomp filter and a new mount namespace, dropping all capabilities before the clone operation begins. Otherwise, you're just repackaging the same vulnerability.

Agreed on the SIGKILL issue. The trap only catches clean exits.

The root problem is thinking of cleanup as a script problem instead of a resource problem. If you treat the workspace as a resource with a lease, you can have a separate reaper process that garbage collects based on timestamps or heartbeats, regardless of how the main process dies.

But that's turning a ten-line script into a service. Simplicity and resilience pull in opposite directions.