Are there any future plans to support a basic subset of tools beyond `shell`

now sure if it helps but for me personally have i have been starting the chat with my prompt +

You MUST follow these rules (Git Bash default):

PLANNING + REAL‑TIME TODOs

• At the start of any multi‑step task, create a concise todo list with todo_write (atomic, verb-led items). Keep only ONE item in_progress; mark items completed immediately after finishing; cancel unneeded items quickly.
• Before any new edit or run, reconcile the todo list: mark finished, set next in_progress, then proceed.

PARALLEL DISCOVERY MINDSET

• Think in parallel. Before searching, enumerate specific queries (3–5) covering: (a) where logic lives, (b) how it’s wired, (c) types/interfaces, (d) side effects.
• Run independent searches/reads in parallel with multi_tool_use.parallel (codebase_search + grep + glob_file_search + read_file where needed).
• Iterate in batches: batch → read → refine → batch again. Avoid serial drip calls when not required.

TOOL‑FIRST EDITING (NO SHELL MUTATIONS)

• Use apply_patch for ALL tracked file edits. If apply_patch fails 3x, use edit_file.
• read_file targets before editing (re‑read if stale or after failures).
• NEVER mutate tracked files via Python/Perl/sed/awk/PowerShell or any shell one‑offs. Change code via editor tools only; regenerate outputs via scripts.

EXPLORATION AND SEARCH

• Prefer codebase_search for semantic “how/where/what”; use grep for exact symbols; use glob_file_search/list_dir for discovery.
• For large files, plan chunked read_file (offset/limit) around relevant ranges to avoid context bloat.

SHELL USAGE (RUN SCRIPTS ONLY, GIT BASH)

• Use run_terminal_cmd only to run project scripts/regenerations (not to edit files).
• Use Git Bash (bash.exe): bash -lc "cd <repo/subdir> && <cmd>". Always cd first; pass non‑interactive flags; background long jobs with is_background=true.
• Avoid PowerShell‑specific commands.

STATUS, LINTS, OUTPUT

• Provide a 1–3 sentence status update before each tool batch and after meaningful steps.
• After edits, run read_lints on changed files and fix obvious issues (≤3 attempts/file).
• Cite existing code with code references (startLine:endLine:filepath). New code → fenced blocks. Keep answers concise and high‑signal.

PARALLELIZE BY DEFAULT

• Batch independent read/search operations with multi_tool_use.parallel. Sequence ONLY when B needs A’s output.

REPO HYGIENE

• Do not touch generated artifacts directly; change code/overrides and regenerate via scripts.
• Correctness over convenience; no redundant outputs.

If any rule conflicts, prioritize: apply_patch/edit_file > tool‑first edits > parallel discovery > Git Bash for scripts > no shell text mutations.

• Set Git Bash default in IDE

DO: Set terminal profile to Git Bash; run commands via bash -lc "cd <dir> && <cmd>"
DON’T: Use PowerShell as the default terminal

• Install and use fast CLI tools

DO: Install rg and jq; prefer rg/rg --files for searches; jq for JSON inspection
DON’T: Use find/grep (slow/limited) or parse JSON with sed/awk

• Use a strict tool-first session prompt

DO: Paste this prompt that enforces apply_patch/edit_file, parallelization, and no shell mutations
DON’T: Start sessions without it or allow ad‑hoc shell edits

• Enforce apply_patch for edits (edit_file fallback)

DO: Edit tracked code via apply_patch; if it fails 3x, use edit_file
DON’T: Use Python/Perl/sed/awk/PowerShell to mutate repo files

• Re-read target files before patching

DO: read_file the target before editing (re‑read if stale or after failures)
DON’T: Assume file content hasn’t changed since last read

• Prefer codebase_search; supplement with grep/glob_file_search

DO: Use codebase_search for “how/where” questions; grep for exact symbols; glob_file_search to find names
DON’T: Grep the whole tree for vague phrases or read_many files blindly

• Parallelize reads/searches

DO: Use multi_tool_use.parallel for independent read_file/grep/codebase_search calls
DON’T: Run sequential tool calls when outputs don’t depend on one another

• Chunk large reads

DO: Use read_file offset/limit for big files; widen context only where necessary
DON’T: Pull entire massive files when only portions are needed

• Run scripts only via run_terminal_cmd

DO: Use run_terminal_cmd to run project scripts (e.g., bash -lc "cd scripts && python build_common_drug_mapping.py")
DON’T: Use run_terminal_cmd to edit files or perform shell text substitutions

• Avoid shell-based file mutations

DO: Edit via editor tools; regenerate outputs from scripts
DON’T: Use sed/awk/Python/Perl to rewrite tracked files

• Maintain todos and micro status updates

DO: Track multi-step work with todo_write; one in_progress; mark complete immediately; brief 1–3 sentence updates
DON’T: Skip status or leave todos stale across steps

• Use proper code citation

DO: Use code references for existing code and fenced blocks for new code
DON’T: Paste giant blobs or mix formats

• Background long-running commands

DO: Set is_background=true for servers/watchers
DON’T: Block the session with foreground long jobs

• Minimize output

DO: Return high‑signal, skimmable info; link to code references
DON’T: Dump full file contents or verbose logs

Examples

• Parallel search

multi_tool_use.parallel over:
• codebase_search: “Where are SIG_* composed?”
• grep: "SIG_.*" in scripts/build_common_drug_mapping.py
• glob_file_search: "build_mapping.py"

• Edit flow

read_file target → apply_patch minimal diff → read_lints on that file
If errors: fix via apply_patch (≤3 tries), else edit_file fallback

• DON’T shell mutate

Avoid: bash -lc "sed -i 's/foo/bar/' scripts/build_common_drug_mapping.py"
Instead: apply_patch the specific lines

• Script run

bash -lc "cd scripts && python build_common_drug_mapping.py"
DON’T: Regenerate via pseudo-scripts in messages; always run the real script

• NEVER shell-grep. Use grep (output_mode=files_with_matches, head_limit=50) first; escalate to content (-C 2) only for shortlisted files.
• ALWAYS batch independent searches with multi_tool_use.parallel (codebase_search, grep, glob_file_search).
• After tool results return, IMMEDIATELY read the top file regions with read_file (offset/limit), then apply_patch.
• Zero results → refine queries and re-run IN PARALLEL; don’t pause or summarize.
• Heuristics: prefer files_with_matches + head_limit; avoid whole-file reads unless necessary; skip redundant summaries; move directly to the next tool call.

Priority if conflicts: apply_patch/edit_file > tool-first (grep/glob/codebase_search/read_file) > parallelize > Git Bash for scripts > no shell text mutations.

Not everything is needed here but on windows especially it does get annoying at times so i just use this

also very anecdotal but what i found is to use the above prompt intially with gpt and then codex models will apply patch after i switch in the same chat window

also very anecdotal but what i found is to use the above prompt intially with gpt and then codex models will apply patch after i switch in the same chat window

@editnori your prompt seems to contain instructions tailored towards Claude Code or some kind of other coding agent because Codex only actually has a few tools calls: shell, update_plan and view_image.

@fouad-openai @ae-openai @pakrym-oai are there any future plans for this feature?

its just a consolidation of what i found others recommended in various issues. That being said you are right some of the thigns i added is just extra that is probably ignored in the prompt. I wasn't sure exactly of which tool calls codex used so i defaulted to using this list. Should probably shorten it to those 3 tools. surprised apply patch isn't one of them I wonder why?

Edit: I actually am so confused if it isnt using apply_patch because i have been getting codex models to apply patches consistently with this prompt see attachment.

<img width="1022" height="641" alt="Image" src="https://github.com/user-attachments/assets/a332163b-c9dc-4cf5-a9d9-323779631636" />

We hoisted apply_patch to a top-level tool and are experimenting with other tools in the future that we could give to the model to improve performance and ergonomics. Thanks a lot for the write-up and suggestions here, I've shared them with the team.

Im curious why codex didnt decide to expose a set of primitive tools for the agent for doing search and basic file patching, writing, reading, renaming, moving, etc

It seems it would make overall permissions much easier/safer and also could make these operations more efficient and ergonomic for the agents