I saw a post about a critical PHP vulnerability and wanted to know whether my server was affected. I had Coolify open beside it. I gave Codex those two pieces of context through the ChatGPT desktop app and asked it to check.
That request turned into a complete maintenance process: research the issue, inspect the running services, reduce exposure, wait for a patched release, upgrade, and verify the result. I still had to authorize changes and unlock my SSH key. I did not have to work out each command or carry the investigation between browser tabs and terminal windows myself.
Find the exposure in the running system
The issue was PHP2Shell, tracked as CVE-2026-109618 and CVE-2026-109619. Codex checked official notices instead of treating the social post as the full explanation. Coolify's advisory now documents the affected platform and patched releases.
The next question was which of my services actually used PHP. Codex inspected all 43 running containers through Coolify's server terminal. It found PHP-FPM 8.4.23 inside Coolify itself, which was running version 4.4.6. It found no PHP runtime in the standard locations or PHP processes in the other 42 containers. It also checked the host for a separate PHP service and found none.
That narrowed the work considerably. The application containers did not all need the same update. The management application did.
It also explained why that one container mattered. Coolify manages other services and has access to their configuration and server credentials. An affected management service can put applications at risk even when those applications do not use PHP.
This was an exposure assessment. It did not establish whether anyone had compromised the server.
Stop the dashboard while the apps keep running
At the time of the first check, we were still waiting for the patched Coolify release. I asked whether I could stop Coolify without stopping the applications it managed.
Codex checked the maintainer's guidance and confirmed that the dashboard and proxy run separately. Stopping the management container would interrupt the dashboard, API, deployments, and Coolify background tasks. The existing applications and databases could keep running through the proxy.
I asked it to do that and remind me to patch once the release was due.
SSH access was blocked by my locked key, but the signed-in Coolify terminal still had a server session. Codex used that session to stop the management container. The terminal disconnected, the dashboard stopped responding normally, and a deployed app still loaded through the proxy.
The reminder kept checking the official release page. Once the patch appeared, it reported that the update was available. It kept the reminder active until installation was verified.
Upgrade, then check what is actually running
Coolify v4.4.7 included PHP 8.4.27 with fixes for both PHP2Shell vulnerabilities. I asked Codex to install it, keep my apps running, and stop the reminders after verification.
There was one manual access step: I unlocked my SSH key locally. After that, Codex connected, recorded the running containers, backed up Coolify's database and configuration, and ran the upgrade.
The checks after the upgrade were the useful part:
- Coolify was running version 4.4.7 and reported healthy.
- The PHP-FPM runtime reported version 8.4.27.
- All 38 application and database containers, plus the proxy, retained their original container IDs and start times.
- Requests to the configured application hostnames returned successful responses or redirects.
Those HTTP checks did not test every application feature. They did show that the routes still responded, while the container comparison showed the upgrade had left those workloads running. Codex then disabled the reminders.
Give the agent the outcome
I could have done these steps manually. I would have needed to find the advisories, inspect the containers, understand the proxy boundary, choose a temporary measure, track the release, make backups, update, and check the result.
With the desktop app, I could start with the vulnerability report and my open dashboard. Codex could follow the work across research, the browser, SSH, Docker, and scheduled follow-up. My part was to set the goal, approve the changes, and provide access when needed.
The useful request was to find out whether I was exposed and get the affected service patched while keeping my apps running. That gave the agent a result to verify, beyond simply finishing an update command.