A recent incident has put part of the community on alert: failure It took up hundreds of gigabytes of hard drive space without warning. Within about an hour, a player saw the free space inexplicably plummet.
The source of the problem was traced to a log file called cef_log.txt, part of the Chromium Embedded Framework that the Valve app has been using for years. The case, reported by Reddit user Top_Order_2533, illustrates how a simple log can escalate to unbelievable numbers.
What exactly happened?
After receiving the alert about almost empty space, the affected person checked the storage with an analysis tool and located the focus in the Steam folder: cef_log.txt was around 491 GB and next to it, a second previous file appeared, cef_log.previous.txt, about 68,8 GB.
The reaction was straightforward: close Steam, delete both logs, and relaunch the application. As he later explained, returned to normal and the file did not grow uncontrollably again in subsequent beginnings.
Why did it happen? The community is considering several hypotheses: from a logging loop triggered by a specific event to a network failure or a memory leak that repeats the same note over and over again. There is no official confirmation, but the overabundance of identical entries fits with what was observed.
What is cef_log.txt and why does it exist?
The file in question is a log of Chromium Embedded Framework (CEF), the technology that Steam integrates to render web views within the client. Its function is to store technical messages, usually related to network and connections.
Under normal conditions, these logs are small because they only record specific events. When a bug appears that causes the same incident to be written continuously, the file can inflate in seconds or minutes until consuming a large part of the storage.
Previous cases and signs in the community
This is not the first such warning. A similar incident was documented on GitHub in 2023 with a log of 54 GB on Linux, which was resolved reinstalling Steam from scratch to cut off any corrupt state.
Going back further, a 2019 Reddit post pointed to a bug in the hardware acceleration of web views as a trigger for record growth. Disabling this option in the client settings slowed the massive generation of entries.
There are also mentions of other, less extreme episodes (files of 1 GB or tens of GB). Although the pattern is not simple, reports converge on Linux systems, which could indicate greater exposure in that environment.
How to detect it and what to do if it happens to you
If you notice that the free space drops dramatically for no apparent reason, check the Steam installation folder and, inside, the Directory de logs. Look specifically for cef_log.txt and see if its size is abnormal.
To be safe, completely close the Valve client, delete cef_log.txt (and cef_log.previous.txt if it exists), and reopen Steam. In most reported cases, the file deletion It causes no side effects and releases storage instantly.
If the problem persists, try disable hardware acceleration in the app settings. As a final measure, a clean reinstall Steam often restores correct behavior when there are corrupted states or configurations.
It is also a good idea to monitor disk usage from time to time and, if you use scripts or maintenance tools, consider periodically reviewing them. log files to avoid unpleasant surprises.
Who does it affect and what is its scope?
The collected alerts focus on Linux, although there's no conclusive evidence that this is a flaw exclusive to that system. In any case, the overall impact appears limited: approx. 2,67% of Steam gamers use Linux, compared to 1,77% on Mac and a large majority on Windows.
To date, Valve has not commented on the incident, although it has occasionally released emergency patches for issues related to Steam and Steam Deck.
This episode makes a clear point: even a text file can become a headache if a bug triggers uncontrolled writing; luckily, clearing the log and relaunch Steam has been sufficient in most cases, and there are simple alternatives if it reappears.
