Codex known logging bug

 See:

• https://github.com/openai/codex/issues/28224
• https://www.reddit.com/r/OpenAI/comments/1ucf4px/openai_codex_has_a_bug_that_could_kill_your_ssd/ 

 Fix:

It is perfectly safe to disable or delete the ~/.codex/logs_2.sqlite file. This file is used exclusively for local logging and diagnostic data. It does not contain any of your conversation history, user preferences, API keys, or project state.

Codex has a known logging bug that continuously writes massive amounts of data (up to hundreds of gigabytes per year) to this database. Because of this, it is actively recommended to manage or disable it. [1]

How to Safely Disable or Manage It

To stop the file from burning through your physical drive, you can use the following safe methods:

1. Completely delete the file (or directory)
You can safely remove the file or the entire ~/.codex directory if you want to clear up space. Codex will simply recreate the directories/files as needed (though the excessive logging will resume).

rm ~/.codex/logs_2.sqlite

 

2. Redirect logging to RAM (Recommended for Linux/macOS)
To prevent the continuous disk writes without breaking the logging functionality, you can create a symlink to redirect the file into your system's /tmp/ folder. Data in /tmp/ is stored in RAM and is wiped when you restart your computer. 

# Ensure the codex directory exists
mkdir -p ~/.codex

# Move the current file out of the way or delete it
rm ~/.codex/logs_2.sqlite

# Create a symlink to /tmp
ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite

3. Clear the associated WAL and SHM files
If your disk is suddenly filling up, check for logs_2.sqlite-wal and logs_2.sqlite-shm files. These SQLite temporary and Write-Ahead Log (WAL) files can grow to tens of gigabytes. You can safely delete these whenever the Codex application or CLI is fully closed.

 

Alternative: The Ultimate "Zero RAM" Fix

If you want to completely stop the logging without using any RAM or disk space, you can link the file to dev/null (the system black hole). This discards the logs instantly.

Run these commands:

rm ~/.codex/logs_2.sqlite
ln -s /dev/null ~/.codex/logs_2.sqlite

However, the above does not work. Codex cannot start and refers to missing the database. So have to use the /tmp redirect.

To automate this and ensure that Codex never consumes too much of your Mac's RAM, we can create a tiny, lightweight background script using macOS's built-in launchd system.

This script will run completely hidden in the background and silently wipe the RAM log file every 2 hours without interrupting your work.

---

Step 1: Create the Automation Configuration

Open your Terminal app and copy-paste this single, large command block. Press Enter to run it:

bash

cat << 'EOF' > ~/Library/LaunchAgents/com.user.clear_codex_ram.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://apple.com">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.clear_codex_ram</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/sh</string>
        <string>-c</string>
        <string>/usr/bin/killall -STOP Codex 2>/dev/null; /bin/echo -n "" > /tmp/codex_logs_2.sqlite; /usr/bin/killall -CONT Codex 2>/dev/null</string>
    </array>
    <key>StartInterval</key>
    <integer>7200</integer>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>
EOF

(Technical note: The 7200 value represents 7,200 seconds, which tells macOS to run this exactly every 2 hours. It safely pauses Codex for a millisecond, truncates the file to 0 bytes, and resumes Codex).

  

Step 2: Activate the Script

Now, tell macOS to register and start running this background task immediately by pasting this command into Terminal:

bash

launchctl load ~/Library/LaunchAgents/com.user.clear_codex_ram.plist 

 

How to remove it in the future

If Codex ever releases an official software update that permanently fixes this bug, you can completely uninstall this background task by running these two commands:

bash

launchctl unload ~/Library/LaunchAgents/com.user.clear_codex_ram.plist
rm ~/Library/LaunchAgents/com.user.clear_codex_ram.plist

Your Mac is now fully protected! The symlink keeps the heavy writes completely off your physical SSD, and this background script keeps the log file from hoarding your active system RAM.

Daemonsize a service

To daemonize a Linux process means to run a program continuously in the background so that it detaches from your terminal and stays alive after you log out. [1, 2]

The industry-standard approach is to let systemd handle the service lifecycle. However, you can also do this directly via the command line or within your application code.

Method 1: Using systemd (Recommended)

This is the standard and most reliable method for modern Linux systems. [1, 2, 3]

1. Create a service configuration file:
   Open a new terminal and create a systemd configuration file:
   bash

   sudo nano /etc/systemd/system/my_python_daemon.service
   

   
   
2. Add the service definition:
   Paste the configuration template below. Replace the absolute paths, user, and script names with your project parameters:
   ini

   [Unit]
   Description=My Python Daemon App
   After=network.target
   
   [Service]
   Type=simple
   User=your_linux_username
   WorkingDirectory=/home/your_linux_username/my_project
   ExecStart=/home/your_linux_username/my_project/venv/bin/python /home/your_linux_username/my_project/main.py
   Restart=on-failure
   
   [Install]
   WantedBy=multi-user.target
   

   
   
3. Reload and start your new daemon:
   Run these commands sequentially to register, initiate, and verify your background process:
   bash

   sudo systemctl daemon-reload
   sudo systemctl enable my_python_daemon.service
   sudo systemctl start my_python_daemon.service
   sudo systemctl status my_python_daemon.service
   

   
   

Method 2: Using Supervisor (Alternative Process Manager)

If you do not have root (sudo) privileges to systemd, or prefer a dedicated application-level manager, use Supervisor. [1]

1. Add a program configuration:
   Create a configuration file within the Supervisor configuration directory:
   bash

   sudo nano /etc/supervisor/conf.d/my_python_daemon.conf
   

   
   
2. Add the tracking parameters:
   Provide the exact path to your venv binary inside the command argument:
   ini

   [program:my_python_daemon]
   command=/home/your_linux_username/my_project/venv/bin/python /home/your_linux_username/my_project/main.py
   directory=/home/your_linux_username/my_project
   autostart=true
   autorestart=true
   user=your_linux_username
   stderr_logfile=/var/log/my_python_daemon.err.log
   stdout_logfile=/var/log/my_python_daemon.out.log
   

   
   
3. Update Supervisor:
   Tell Supervisor to look for new configurations and start the daemon:
   bash

   sudo supervisorctl reread
   sudo supervisorctl update
   

   
   

Crucial Best Practices

• Avoid Relative Paths: Inside your daemonized Python scripts, avoid using relative file lookups like open("config.json"). Daemons often run relative to the root directory / or system folders unless explicitly specified by WorkingDirectory. [1]
• Reading Logs: Since the script runs invisibly in the background, you can inspect your print statements or unhandled tracebacks via the system journal:
  bash

  journalctl -u my_python_daemon.service -n 50 -f