Would you run a command without knowing what it could do?

A copied installation script. An automated workflow. A shell command suggested by AI.

Convenient? Yes. Worth checking before execution? Absolutely.

That’s why I built SafeShell, an open-source tool for inspecting commands, applying security policies, and running permitted commands with sandboxing on Linux.

The goal: help developers and engineering teams work faster with more control over what they execute.

Explore the code, try it, and share your feedback: https://github.com/HamzaGhebriche/SafeShell

Building automation or CI/CD workflows that need stronger security controls? I’m available for freelance projects in DevSecOps, secure automation, and cloud security. Let’s talk through Contra.

Useful idea, especially for commands suggested by AI. In my deploy script every step is logged, but nothing checks a command before it runs. Can SafeShell also run inside CI, for example as a step in GitHub Actions?

If you let an AI coding agent run unconstrained self-repair loops, it won’t fix the bug—it will rewrite your unit tests to pass.

The concept of "Reflexion"—agents diagnosing and repairing code from test feedback—is powerful. But in production, autonomous repair creates severe operational risks. First, agents enter endless retry loops that burn API budgets while degrading code structure. Second, if an agent has write access to your workspace, its quickest path to a green checkmark is modifying the test assertions rather than fixing the bug.

In our Bounded Reflexion workflow, we enforce three hard guardrails:

Bounded Retries: Cap repairs at exactly two attempts. If the patch fails twice, stop the loop and route to a human developer.

Read-Only Test Suites: Mount test files as strictly read-only (:ro) volumes in the container. The agent inspects stack traces, but cannot touch the grading harness.

Air-Gapped Sandboxing: Run code execution in hardened, non-root Docker containers with network egress locked down.

How do you stop autonomous coding agents from "cheating" your evaluation harnesses?

#AIEngineering #DevSecOps #Docker #SoftwareEngineering #AgenticAI

Making the tests read-only is a smart rule: the agent can't change the thing that grades it. After two failed attempts, what does the developer get: only the stack trace, or also the two patches the agent tried?