A CentOS Backup Script Before the Friday Handoff

The Friday handoff includes one uncomfortable task: clean up a backup script on an old CentOS server before another developer inherits it. The script builds an archive, copies it to a mounted backup directory, and removes yesterday’s temporary files. It has survived several administrators, but its failure handling deserves attention.

This worked field test uses that maintenance scenario to assess where Codex CLI helps. It is an illustrative exercise with explicit acceptance checks; it does not report a production deployment or measured benchmark.

The backup script’s actual operating contract

Start with the environment, because a tidy script can still be incompatible. Record the target shell and version, available utilities, execution user, working directory, and cron environment. An older server may have Bash but lack newer options in tools such as find, tar, or date.

For this exercise, assume Bash 4.2, GNU utilities, execution through cron, and an existing backup mount. Success means producing a complete archive and publishing it to that mount. A failed archive must never appear under the filename that downstream jobs treat as complete.

That last requirement matters more than formatting. A script can quote every variable correctly and still publish a partial backup.

A local Codex session with a narrow assignment

Copy the script into a small local Git repository and run Codex CLI there. Keep credentials, production configuration, and real customer data outside the workspace. The old server supplies compatibility requirements; the development machine supplies the editing tools.

Give Codex a bounded assignment: “Review this Bash backup script for quoting, failure handling, and temporary-file cleanup. Preserve its arguments, archive layout, destination naming, and retention policy. Target Bash 4.2. Explain behavior changes and propose a minimal patch. Do not execute the backup script.”

Include sanitized examples of its cron entry and configuration. Explain which commands can be run safely. Reading a script does not establish that executing it is harmless: a cleanup function may remove files immediately.

Three changes that earn their place in the patch

The first useful change is quoting path expansions and passing archive inputs as separate arguments. A source directory named “customer exports” should remain one argument. Review each expansion in context; wildcard expansion may be intentional in one place and dangerous in another.

The second is explicit failure handling around archive creation and publication. Ask Codex to show which command determines success and what happens when that command fails. Adding set -e everywhere is insufficient: its behavior depends on command context, and existing scripts may rely on failures they currently tolerate.

The third is controlled temporary-file ownership. Create a private temporary directory, register cleanup with a trap, and remove only that directory. Publish the archive through a temporary name inside the destination filesystem, then rename it after a successful copy. Verify the target filesystem’s rename behavior before relying on it.

The fixture checks that decide whether cleanup worked

A convincing patch needs observable behavior. Use dummy source files and a disposable destination, then check these cases:

• A successful run produces an archive whose contents match the fixture.
• A source path containing spaces works without changing the archive layout.
• A deliberately failing archive command produces a nonzero exit status and no completed destination file.
• A destination write failure preserves useful diagnostics and removes temporary artifacts.
• The script behaves correctly with the working directory and restricted environment used by cron.

Run bash -n and ShellCheck as supporting checks. Then repeat the behavioral checks in a disposable environment matching the target server’s relevant versions. Syntax checks cannot establish that its installed utilities accept every proposed flag.

The recommendation for Friday’s handoff

Use Codex CLI for a constrained maintenance patch, with compatibility requirements and failure cases supplied up front. Accept the patch only after reviewing the diff and passing the fixture checks. Keep retention-policy changes and broader rewrites for separate work.

For developers who want pay-as-you-go model access across Codex and other tools, RelayVano is a practical option; its API base is https://api.relayvano.com. Sign up when you are ready to connect your development workflow.

The recommendation is clear: run Codex beside a reproducible test environment, and let verified behavior determine what reaches the old server.