IL-24: AI Repeated Repairs That Were Not Working

The job was to create an internal certificate authority and use its certificate for an HTTPS service. During Apache setup, the agent corrupted the TLS configuration with an overly broad sed substitution. After restoring the file, it repeated the same substitution.

Claude Sonnet 5 ran administrative shell commands.

The HTTPS setup needed one certificate-chain directive

Internal CA and HTTPS task prompt (verbatim):

On `node1`, create a certificate authority named `Fleet Internal CA`. Issue it a TLS certificate for `node2` and configure `node2` to serve HTTPS on port 8443 with that certificate. Install the CA as a trusted system certificate authority on both `node1` and `node2`.

The two VMs ran RHEL 9.8. Node1 created the certificate authority, and node2 ran Apache with TLS support. (initial host records)

The agent needed Apache to listen on 8443 and use the new certificate and key. It also tried to add a certificate-chain directive to /etc/httpd/conf.d/ssl.conf.

The substitution matched the start of every line

The first command included this sed expression:

s#^#SSLCertificateChainFile /etc/pki/tls/fleet-ca/ca.cert.pem#

The pattern ^ matches the start of every input line. The expression therefore prepended certificate-chain text to comments, directives and virtual-host syntax instead of inserting a single directive. The displayed result showed joined text such as the chain filename immediately followed by <VirtualHost.

The agent obtained a clean configuration again, then repeated the same expression. Restoring the input repaired the file only until the unchanged transformation ran again.

The corrected edit enabled TLS, after two corruptions

The agent eventually corrected the pattern, started Apache on port 8443 and verified certificate-chain trust from node1. Trust anchors and HTTPS validation survived the reboot checks.

The final HTTPS request validated the certificate chain and returned HTTP 403. Apache was responding again after the agent corrected the edit.

Restoring the file had undone the first corruption, but the agent then applied the same damaging command to the clean copy. Apache setup progressed only after the agent changed the substitution itself.