Setup Codex sandbox

[white238]

This is aimed at a good base for using the Codex Sandbox on LC. I put in effort to allow it to work on non-LC machines but haven't tried it personally. For example, the compute/login node script will default to compute if not on LC and put some guardrails recommended by ChatGPT that might sandbox you outside of a sandbox.

To be very clear, these are here to help but cannot be fully trusted. Only use Agentic AI on repos that you know dont have any work you care to lose since it can still revert/commit/delete.

[tupek2]

If you are interested in getting into the next level of this agentic stuff (which I haven't done yet), I'd recommend you research custom /slash commands (maybe for build or testing), and also the use of LLM hooks (where, for example, you can make a hook that after the agent makes code changes, it automatically builds the code, runs the tests, makes style, etc). Just something to be aware of that I'm not sure the initial tutorial covered. I'm personally more interested in these things than skills, which are mostly ignored.

[tupek2]

Having done this stuff now for a bit, all the reading and experience I have says not to have a common AGENTS.md file for the team. The skills are fine, also the sandboxing is important of course, but I will setup my AGENTS.md to be very specific to the computer I'm on, the task I'm doing, the things I see the LLM do wrong. its an iterative process. You could look at my current AGENTS.md and see its not something that makes sense to be common or shared by the team. Every LLM session injects this into context, and its very situation specific what I want to be injecting into my sessions like this. So, my recommendation is we rename this file (claude as well, though I guess claude should probably be deleted for now) to STARTER_AGENTS.md or SUGGESTED_AGENTS.md or INITIAL_AGENTS.md. People can choose to copy that to use as their own AGENTS.md (or not) as they see fit. Otherwise I'll be dealing with merge conflicts on the file forever, and I'd argue its best for people learning this stuff to figure out how to manage their own AGENTS.md to get experience.

[tupek2]

we would then put agents.md, AGENTS.md, CLAUDE.md and claude.md in .gitignore

[white238]

Removed the agents file. Do you think its worth it to add an ignore if we are recommending against them?

[tupek2]

We are not recommending against them. We are highly encouraging them. But its an individual thing, so I've added CLAUDE.md, claude.md, AGENT.md, agent.md to my local git ignore.

[white238]

done.

[tupek2]

Is this likely to default to everyone running debug by default? Its pretty common for people to tell me: 'this or that smith problem is slow' only for me to (after a day of work) realize they were default building debug. Now my default response to these this is: just build in release (which they often still ignore). I personally rarely build, test, or debug in debug. Maybe we want a release_build skill, and a debug_build skill.

[white238]

Swapped to RelWithDebInfo by default unless specifically asked for a debug build.

[tupek2]

Release please. I people want to debug, the should probably run in debug.

[white238]

Maybe we should discuss this in the technical meeting. RelWithDebInfo is nearly as fast (-O2 vs -O3) but does get you debug symbols. I was envisioning these files are mainly for out development. Are you expecting them to be used by people outside of our team? I feel this is a healthy middle ground and if someone really cares they can put it in their agents file or just tell it to use release.