Summary
Today working_directory only sets the default CWD for relative-path resolution used by native file tools (read, file_search, glob, grep, view, write, edit, shell). It does not prevent those tools from reaching paths outside that directory — absolute paths and .. traversals are served as-is.
Please add an opt-in mechanism that makes working_directory (or an equivalent allow-list) an actual access boundary for the SDK's built-in file tools. Searching the rest of the filesystem provides no value for repo-scoped agent workflows and actively harms them by:
- pulling unrelated files (
%TEMP%, ~/.gitconfig, sibling repos, log dumps) into LLM context, polluting reasoning and inflating tokens;
- creating an obvious data-exfiltration surface in any production deployment;
- forcing every embedder to either write a custom permission handler or disable native tools entirely (
available_tools=[]) and reimplement file access with custom tools — which is what we ended up doing.
Documentation-only clarification is not enough; the safer default is what most users already assume the option does.
Summary
Today
working_directoryonly sets the default CWD for relative-path resolution used by native file tools (read,file_search,glob,grep,view,write,edit,shell). It does not prevent those tools from reaching paths outside that directory — absolute paths and..traversals are served as-is.Please add an opt-in mechanism that makes
working_directory(or an equivalent allow-list) an actual access boundary for the SDK's built-in file tools. Searching the rest of the filesystem provides no value for repo-scoped agent workflows and actively harms them by:%TEMP%,~/.gitconfig, sibling repos, log dumps) into LLM context, polluting reasoning and inflating tokens;available_tools=[]) and reimplement file access with custom tools — which is what we ended up doing.Documentation-only clarification is not enough; the safer default is what most users already assume the option does.