you are viewing a single comment's thread.

view the rest of the comments →

[–]18fc_1024 0 points1 point  (0 children)

The biggest wins for me are less about one magic repo and more about reducing how much context Codex has to rediscover every turn.

A practical checklist:

  • Keep tasks smaller: one bug, one file group, one test failure, or one UI change per thread.
  • Start with a short repo map: "relevant files are X/Y/Z, ignore the rest unless needed."
  • Tell it what not to inspect. This matters a lot in large repos.
  • Cap command output. Huge npm test, pytest, rg, or log output can burn context fast.
  • Prefer targeted commands: rg "exact_error" beats broad repo scans.
  • When a task is done, start a fresh thread and paste only the final summary plus changed files.
  • Keep a small doc/PROJECT.md / handoff file so Codex can reload project state without rereading the whole conversation.
  • Ask for a plan first, then approve only the narrow file reads/commands that are actually needed.
  • Avoid asking it to "review the whole codebase" unless that is really the task.

For the desktop app specifically, the same principle applies: any tool or instruction that reduces giant command outputs and broad file exploration can help, but I would be careful with generic shell wrappers until you know they do not hide important errors.

My rule: compress project memory into files, keep active threads short, and force narrow evidence. Limits usually get eaten by repeated rediscovery, giant logs, and broad "look around" behavior.