Skip to main content

AI Coding Tools and SSD Wear: Acceptable Use Policy Gaps

A Codex bug report extrapolated 640 TB/year of SQLite log writes. The fixes came in waves through July. Here are the AUP clauses and Codex settings to add.

9 min readBy Johnie T YoungUpdated 16 days agoLast reviewed
AI Coding Tools and SSD Wear: Acceptable Use Policy Gaps

A hand holding a black pen over a sheet of paper, representing AI coding tools infrastructure risk acceptable use policy 2026 Image: Pexels, used under the Pexels License.

TL;DR: A June 14, 2026 GitHub issue showed OpenAI Codex writing its SQLite feedback log so hard that one machine logged about 37 TB in 21 days, which the reporter extrapolated to roughly 640 TB a year. OpenAI merged fixes on June 22 and 23 and more on July 9, shipped across releases 0.142.0, 0.143.0 and 0.145.0. Most AI acceptable-use policies say nothing about what a tool does to the machine it runs on. This guide adds those clauses.

Update, October 10, 2026: This guide was rechecked against the GitHub issue, the pull requests and OpenAI's Codex configuration reference. The earlier version said the bug was first reported on June 22 and that OpenAI closed it that day with two fixes. The issue was opened on June 14, three fixes merged on June 22 and 23, four more followed on July 9, and GitHub shows the issue closed on July 12. The "85%" figure was the reporter's own estimate, not OpenAI's. We also removed unsourced claims about how other coding tools cache data and download models.


What happened with OpenAI Codex

On June 14, 2026 (UTC), GitHub user 1996fanrui opened issue #28224 in OpenAI's Codex repository: "Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance." Notebookcheck covered it on June 22.

The writes went to a local SQLite feedback log database, ~/.codex/logs_2.sqlite, plus its -wal and -shm files. The reporter's numbers:

Measurement (one machine) Value
Uptime about 21 days
Written to the main SSD about 37 TB
Reporter's yearly extrapolation roughly 640 TB
On a 1 TB SSD about 640 full-drive writes per year
Share of retained log bytes at TRACE level about 70.7%

The reporter added that some consumer SSDs are rated around 600 TBW, "so this could consume roughly a full drive's warranted write endurance in less than a year."

Why so much? OpenAI's own pull requests explain it. The local SQLite log sink "enables TRACE for every target," and every successful Responses WebSocket event produced "three local log records: the full payload at TRACE, an OpenTelemetry log event, and an OpenTelemetry trace event." Notebookcheck added that the sink ignored the standard RUST_LOG variable, "so there's no obvious way to turn it down."

GitHub issue 28224 in the openai/codex repository, showing the reporter's June 23 update and the three merged pull requests Screenshot: issue #28224, openai/codex on GitHub. GitHub shows the open date in the viewer's time zone.


The fix came in waves, not in one patch

Date (UTC) What happened Source
June 14, 2026 Issue #28224 opened GitHub issue
June 22, 2026 PR #29432 merged: stop logging every Responses WebSocket event PR #29432
June 22, 2026 PR #29457 merged: filter noisy targets from persistent logs PR #29457
June 22, 2026 Release 0.142.0 published, with both PRs issue update, release page
June 23, 2026 PR #29599 merged, because high-volume TRACE events kept "reaching SQLite" PR #29599
July 8, 2026 Release 0.143.0 published release page
July 9, 2026 Four more PRs merged (#31789, #31790, #31791, #31792) PRs
July 11, 2026 Separate issue #32496 opened about the desktop app (still open) GitHub issue
July 12, 2026 GitHub shows issue #28224 closed GitHub issue
July 21, 2026 Release 0.145.0 published, listing #31789, #31792 and #31791 release page

On June 23 the reporter updated the issue: "the following 3 PRs are merged, it could avoid 85% logs(feedback from my codex)." That 85% is one user's measurement on one machine.

The July round shows the first fixes did not cover everything. One PR says MCP service events at TRACE were "the largest retained source and individual rows reached about 2 MiB." Another replaced a full dump of streamed response items, which made "the SQLite copy both redundant and potentially large or sensitive." That last point matters for compliance as much as for hardware: a debug log was holding a second copy of assistant output on the laptop.

Issue #32496, filed July 11, is a different problem in the desktop app: two small JSON files that, over 7 days, "accounted for about 24.9 GB of path-attributed local NVMe writes." It was still open when we checked.

The rust-v0.145.0 release changelog on GitHub, listing pull requests 31789, 31792 and 31791 Screenshot: rust-v0.145.0 release notes, openai/codex on GitHub.

What users reported in the thread

The issue drew 154 comments. A few that show why one patch was not the end of it:

"Activity Monitor showed that the codex process had written about 50 GB of data." (comment on #28224, macOS and the Codex app)

"On ubuntu, using sudo iotop -aoP I can see that Codex writes around 10MB of data per second" (comment on #28224, on version 0.142.0)

"0.143.0 (published today) actually has #29599 in it now, and it works." (comment on #28224, July 8)

And the governance question in one line: "why is it logging at TRACE in the first place ?" (comment).

Workarounds people used

The issue itself lists a workaround: quit Codex, then add a SQLite trigger that ignores inserts into the logs table (CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;). Notebookcheck described symlinking the file to /tmp/ on Linux and macOS and said "the file holds no conversation data, so losing it on reboot is fine." Both are user hacks, not vendor guidance. The governed fix is to update to a release with the patches and then measure.


Why this is a governance gap

If your AI acceptable-use policy covers what data goes into the tool, who owns the code that comes out and who reviews it, it covers the tool as a service. It does not cover the tool as software running on your hardware. Codex is a local agent: it keeps state on the laptop, writes logs, and runs for as long as the session does. Nothing in a data-and-output policy tells anyone to check what that local process is doing to the disk.

Three things in this incident are policy questions, not bug-tracker questions:

  1. Who notices. The reporter noticed unusually high disk activity and traced it to the log files. Most staff would never look.
  2. Who decides when it is fixed. The reporter closed the issue on an 85% estimate; later fixes and a new issue followed. "Update to the latest version" is not a check.
  3. What the logs held. OpenAI's own PR says the response-item log could be "large or sensitive." A debug database on a laptop is now part of your data map.

A monitor showing lines of colored PHP and HTML code, seen at an angle, representing AI coding tools infrastructure risk acceptable use policy 2026 Image: Unsplash.


What your AUP needs to add: 6 clauses

Copy these into your AI acceptable-use policy and fill in the brackets.

1. Approved endpoints. "AI coding tools that run locally (command-line tools, desktop agents, IDE agents) may only be installed on company-managed endpoints enrolled in [MDM tool]. Personal devices are excluded."

2. Version floor after vendor patches. "When a vendor ships a fix for a security, data or resource-use defect in an approved AI tool, affected endpoints must run the fixed version within [7/14] days. IT will name the minimum version in the approved-tools register."

3. Report unusual resource use. "Employees who see unexpected disk, CPU, network or API cost activity from an AI tool must report it to [IT channel] within [24] hours. Reporting a tool problem is never a disciplinary matter."

4. Unattended runs. "Running an AI agent unattended for more than [2/4/8] hours requires manager approval and an entry in the agentic AI register. API keys used for unattended runs must have spending limits."

5. Local logs and caches are company data. "Logs, caches and history files written by AI tools on company endpoints are company data. They may contain prompts, code or model output, are covered by the data classification policy, and must not be copied to personal storage."

6. Admin-managed settings. "Where a vendor supports admin-enforced configuration, IT sets logging, history and telemetry options centrally. Users may not override them."

We dropped an earlier clause that made employees pay for damaged hardware. The Codex reporter found the problem by checking; a clause that punishes the person who notices discourages exactly that.


Codex settings IT can manage

For Codex specifically, OpenAI's configuration reference describes the controls. These are the ones relevant to this incident:

Setting What the reference says it does
requirements.toml "an admin-enforced configuration file that constrains security-sensitive settings users can't override"
Cloud-fetched requirements "For ChatGPT Business and Enterprise users, Codex can also apply cloud-fetched requirements."
log_dir "Directory where Codex writes log files; defaults to $CODEX_HOME/log"
sqlite_home "Directory where Codex stores the SQLite-backed state DB used by agent jobs and other resumable runtime state."
feedback.enabled "Enable feedback submission via /feedback across local clients (default: true)."
history.persistence, history.max_bytes Control whether transcripts are saved to history.jsonl and cap the file size
otel.log_user_prompt "Opt in to exporting raw user prompts with OpenTelemetry logs."

Read the reference for which keys requirements.toml actually accepts before you promise anything in policy. The point for the AUP is clause 6: if the vendor gives admins a file users cannot override, use it.


How to audit which AI coding tools are in use

  1. Endpoint software inventory. Most MDM platforms can list installed applications. Search for the coding tools your teams use, including command-line tools installed by package managers, which may not show up as applications.
  2. Expense and card review. Look back six months for AI subscriptions on expense reports and corporate cards.
  3. Ask engineering leads. Self-reporting catches tools on personal accounts that never hit company billing.
  4. Check the Codex log on machines that run it. Look for logs_2.sqlite under ~/.codex and note its size and how fast it grows over a working day. Compare with the version installed.
  5. Check drive health on developer machines. Compare total bytes written with the drive's rated endurance (TBW) and flag drives that are well along.

Practical checklist: 8 items for IT and compliance teams

  • 1. List every AI coding tool on company endpoints (MDM inventory)
  • 2. Update Codex to 0.145.0 or later, then re-measure disk writes on a few machines
  • 3. Check drive write totals on machines that ran Codex before the June and July fixes
  • 4. Add the six clauses above to your acceptable-use policy
  • 5. Set spending limits on API keys used by agents
  • 6. Decide which Codex settings IT manages through requirements.toml
  • 7. Add AI tool logs and caches to your data map
  • 8. Subscribe someone to the vendor's issue tracker or release notes for each approved tool

Our take

The bug itself got fixed. What is worth keeping from it is how it got fixed: a user measured it, the vendor merged the first fixes eight days later, the reporter closed the issue on their own 85% estimate, users kept reporting writes on the patched version, and a second round merged on July 9 and shipped in 0.145.0 on July 21. A separate desktop-app issue was still open when we checked. That is a normal vendor bug cycle. Your policy should assume it, not assume one patch ends it.

The detail we would put in front of a privacy team is in PR #31792: a debug log was keeping a copy of response items that OpenAI itself called "potentially large or sensitive." Logs on laptops rarely make it into a data map. AI agents make them bigger and more interesting.

For deeper coverage of agent approvals, see our guide to governing unattended AI coding agents. For visibility into which tools are in use at all, the shadow AI governance guide covers inventory methods.

How we checked this

We read GitHub issue #28224 and its comments, seven pull requests (#29432, #29457, #29599, #31789, #31790, #31791, #31792), the 0.142.0, 0.143.0 and 0.145.0 release pages, issue #32496, OpenAI's Codex configuration reference, and Notebookcheck's June 22 report: 6 sources, counting the pull requests and the release pages as one each. Four community quotes come from comments on the issue; we did not use Reddit. We found no OpenAI post or video about the bug, so there is no embed. Every fact above has a row with a verbatim quote in our source log. Last reviewed: October 10, 2026.


Tagsai-governanceacceptable-use-policyai-coding-toolsshadow-aiinfrastructure-risk

Legal disclaimer

This article is published for informational and educational purposes only. It does not constitute legal, regulatory, or professional compliance advice and should not be relied upon as such. AI governance requirements vary by jurisdiction, industry, and organizational context. Always consult a qualified legal or compliance professional before implementing policies or making decisions with regulatory implications.

About the author

Johnie T Young

Governance & Regulation Desk

Covers AI laws, regulator orders and court rulings, and what each one means for a team of ten. Posts start from the statute or the order itself, with every fact traced to a row in a source log.

  • Starts from the statute or order
  • Every fact traced to a source row
  • Dated checks on each post