I also want to flag local resource usage with Codex. I use Process Lasso while working with Codex, but my CPU can still jump as high as 67%, and my RAM usage is currently around 62% on a machine with 48 GB of RAM. That means close to 30 GB of memory is being used, which seems excessive when Codex is running browser/debugging tasks. I think Codex needs better local resource management, such as a lightweight mode, CPU/RAM usage limits, automatic throttling, fewer background browser processes, automatic cleanup of unused tabs, and a visible resource dashboard showing what Codex is using. Users should be able to set a limit so Codex can keep working without heavily loading their computer.
This is what repository changelog.md file is for. Personally I also add a “release” instructions, so that codex produces a handoff file in releases folder.
This way next agent of needs history has options between quick git cli commands, full changeling read (mine are clearly parsable) or read releases folder and specific release details.
Thanks—the changelog/release handoff idea is useful, but it is not quite what I’m requesting. I’m not asking Codex to block PRs. I’m asking it, before submitting a new PR, to automatically skim the titles and summaries of all previous PRs, group related work, inspect the relevant PRs more deeply when needed, and compare the proposed change against that history.
The goal is for Codex to report whether the new PR reverses or regresses earlier work and whether it genuinely moves the project forward. A CHANGELOG can help as an input, but it is manually maintained and may be incomplete or stale; it is not the same as checking the repository’s actual PR history.
Thanks—the changelog/release handoff idea is useful, but it isn’t quite what I’m requesting. I’m not asking Codex to block PRs; before submitting a new PR, I want it to automatically skim the titles and summaries of all previous PRs, group related work, inspect the relevant PRs more deeply when necessary, and compare the proposed change against that history. The goal is both to ensure the new PR does not reverse or regress earlier improvements and to provide evidence that the proposed change is genuinely better than the current version—not merely different or non-regressive—using relevant tests, audits, metrics, or before-and-after comparisons. A CHANGELOG can be a helpful input, but because it is manually maintained and may be incomplete or outdated, it is not a replacement for checking the repository’s actual PR history.
Building CallBack HVAC has made me a daily, hands-on Codex power user—not just someone experimenting with it. I use Codex across product development, browser workflows, SEO, analytics, and day-to-day business operations, and I naturally pay attention to where the experience breaks down, how to reproduce the problem, and how it could be improved. That combination of real business context, persistent testing, and detailed product feedback is what led me to create this thread. If you’d like to follow what I’m building and the lessons I’m learning about practical AI-agent use, search LinkedIn for Christopher M. Bagley, founder of CallBack HVAC. My LinkedIn username is c-bagley.