Enable Web Search by default

~/.codex/config.toml

[tools]
web_search = true

How does tools.web_search differ from sandbox_workspace_write.network_access? Is the latter necessary to make the former work? Does the latter enable network access for tools/commands other than web search?

Is the latter necessary to make the former work? Does the latter enable network access for tools/commands other than web search?

Network Access seems to be similar to HTTP requests like curl, while Web Search is a model-side tool (OpenAI Documentation). I believe these two are not related; Web Search can be used even without enabling Network Access.

It will also nice in vscode to be able to enable/disable web search X single prompt

Precisely this, why is websearch deactivated by default? This forces the LLM to use outdated information.

why is websearch deactivated by default

@codyseally Because network access (including web search) provides a vector by which things that might be secret in your environment could get leaked; and that's not really a safe default to have, particularly when the way a lot of people may use this agent doesn't require it to have search/network capability enabled all the time.

If you want to enable it by default, you can already do that in the config, as was pointed out previously.

@codyseally Because network access (including web search) provides a vector by which things that might be secret in your environment could get leaked; and that's not really a safe default to have, particularly when the way a lot of people may use this agent doesn't require it to have search/network capability enabled all the time.

This is true but since ChatGPT does not use continual learning, its knowledge is fixed at its training cutoff date. This limitation affects awareness of third-party dependency updates, API changes, new libraries, and ongoing issues such as bug fixes or pull requests. Similar to hallucinations, the model cannot reliably recognize when its information is outdated. In environments with web access, ChatGPT can retrieve up-to-date information, but without it, the model cannot autonomously detect or correct gaps in its knowledge.

@bhack Which is why there is a configurable option that lets you enable it for the session; or globally via the config file if you so desire.

How can balance security and a static knowledge cutoff if I cannot enable X prompt web access in the ide extension?

See also more sophisticated requests like https://github.com/openai/codex/issues/2563

> why is websearch deactivated by default @codyseally Because network access (including web search) provides a vector by which things that might be secret in your environment could get leaked; and that's not really a safe default to have, particularly when the way a lot of people may use this agent doesn't require it to have search/network capability enabled all the time. If you want to enable it by default, you can already do that in the config, as was pointed out previously.

This is not at all a correct decision. All existing agentic coders (both CLI based and the ones working as VS Code extensions) have web search ON by default, and for a fundamental reason: coding agents are useless without access to the most recent version of the libraries they will need to work with. Your argument above is akin to not giving a browser access to the internet for fear of malicious attackers. Sorry, but it does not hold at all.

Furthermore, finding the toml file to enable websearch manually is not always so easy. For example is you work under WSL, your codex points to :

~/.nvm/versions/node/v22.18.0/lib/node_modules/@openai/codex/bin

but good luck finding the toml file there or in the parent codex dir. Also the original ~/.codex/config.toml does not exist in WSL, nor does the .codex hidden dir. This has thus created a problem where there was none.

To balance security and usability, would it be better to require an additional user permission IN CHAT when Web Search is needed, rather than enabling it through a configuration file?

In programming tasks, due to the Knowledge Cutoff date, the agent may use deprecated or outdated APIs and design patterns, which is obviously something developers do not want to see.

I even observed a very strange example: I explicitly required the agent to check the documentation and Release Notes of the libraries to be used before starting the task. However, after browsing the corresponding API documentation, the agent still used an API that was clearly marked as deprecated.

For example, in the latest version of Zod, z.email() is used to match emails, but the agent still used the deprecated API z.string().email().

I don't see websearch working in the ide period? @MeowShe @rben01

I've set the config and all, triple checked to no avail the same prompt produces a search in the cli version but not the ide version?

coding agents are useless without access to the most recent version of the libraries they will need to work with

Web search is not the only solution to this. Agents are perfectly capable of introspecting the APIs of the libraries they are working with right on the local machine - no web search necessary.

Web search is not the only solution to this. Agents are perfectly capable of introspecting the APIs of the libraries they are working with right on the local machine - no web search necessary.

But the env it is not always local. See https://github.com/openai/codex/issues/2835

@bhack even if the agent is working with a remote env the agent can just run commands to collect the context it needs from the remote environment. no difference between introspecting node_modules locally vs via ssh to a remote environment, for example. I said "local" since that is probably how the vast majority of people are using Codex but same comment applies for remote envs.

Theoretically yes but probably the systems right now need to be improved. One day probably will do naturally this on non local envs off the shelf without complex AGENTS.MD engineering.

But it is not only this.
When you are planning and this planning activity could require candidate dependencies evaluation, the planner needs to access the web search.
If an algorithm or a function is available in that library it needs to evaluate it with search without going to install it and build its "context knowledge" on the introspection of something that is not part of the env.

Definitely, but planning out what dependencies to use is a fairly uncommon task and doesn't support the issue's proposal to "Enable Web Search by default" IMO.

Definitely, but planning out what dependencies to use is a fairly uncommon task and doesn't support the issue's proposal to "Enable Web Search by default" IMO.

It really depends on what it means by default and how much the model could be smart to auto activate the tool.
See https://github.com/openai/codex/issues/2563

In that interpretation it is similar to the performance limits of the reasoning router and it is why we don't have only Auto in the drop-down on OpenAI products UX.

If this issue was about "ask the user to escalate permissions to perform a web search by default" I would be perfectly happy to support it.

And I am also quite in favour of other 'smartly balanced' ways of choosing when to enable web search.

But this issue is basically just "web search exists, turn it on always"; which IMO is not a good default; and if an individual user wants that, they already have the power to do so.

"I don't know how to find the config files on my system" is also not a good reason to enable it by default. That could make a more useful focussed issue around improving the documentation for how to find and configure those files on various systems though. Perhaps even could be a built in command that opens them in the default text editor. But again, that's not a good reason to justify enabling web search by default.

---

Edit: It looks like v0.43.0 will have some search related changes too; didn't look too deep into the specifics of them though, just noticed in passing:

• https://github.com/openai/codex/compare/rust-v0.42.0...rust-v0.43.0-alpha.8
• https://github.com/openai/codex/pull/4511

Why not add a /config within codex and allow the user to turn it on explicitly?

For instance, I wasn't aware web-search is disabled by default. I have been asking codex to 'lookup' stuff on and off and used to wonder why it ends up writing a python script every time and uses BeautifulSoup to parse data and JS / CSS every time! I just stumbled upon this issue just now - so it isn't as though codex wasn't performing network lookups simply because it's been disabled, it was bypassing this restriction every time and writing elaborate scripts to parse search results / visiting URLs willy nilly. Try it: use the latest API on glass UI for this SwiftUI button, perform a web search to be sure. Codex will begin curling URLs and will end up visiting and dumping a dozen webpages within the context.

I really don't see why this isn't available as a configuration option _within_ the tool's /config set of options.

I am getting this:

unexpected status 400 Bad Request: {
"error": {
"message": "Hosted tool 'web_search_preview' is not supported with gpt-5-2025-08-07.",
"type": "invalid_request_error",
"param": "tools",
"code": null
}
}


Agreeing with the above add a simple toggle to turn on/off by default and/or per chat. For now, I have it enabled in ~/.codex/config.toml but that is buried (perhaps intentionally). I'm just going to leave it on always in the current case, but for better security and performance, we should be able to enable/disable on the fly.

Quick info for you:

https://github.com/openai/codex/blob/main/docs/config.md

web_search is deprecated; use the web_search_request feature flag instead.

[features]
web_search_request = true        # allow the model to request web searches

I also support the variant proposed in a comment by @0xdevalias. It is very reasonable that web search is not available by default. It is extremely unreasonable that Codex/the VS Code extension won't ask for access instead of messing about with curl/wget for a second and failing, then telling the user they can't access the internet without telling them how to change it.

I've asked multiple times for Codex to do web search and even giving the URL it always refuses. It would be better if it said "I can't but you can turn on, please accept y/n" or something like that. Right now the discoverability of this feature is 0. I've been using Codex for months only discovered this now.

agreed. I just had a horrible experience where it is unaware it can even have this ability, at least put into the prompt that it can be enabled?

any update on this?

I'm amazed this isnt the default, especially coming from Claude Code.

Codex will write an inline python script to try to scrape or search the web which makes it so much dumber than CC out of the box.

You can enable this feature by adding this to your config.toml file.

[features]
web_search_request = true

We'd like to enable this by default but there are security considerations that we're working through. We generally take a "secure by default" approach with Codex. We need to be thoughtful about default-enabling features that have potential security ramifications.

We generally take a "secure by default" approach with Codex. We need to be thoughtful about default-enabling features that have potential security ramifications.

The issue is that Codex aggresively works around this limitation anyway - it'll curl or write python until it brute-forces its way to web access, which sort of defeats the security concern

We'd like to enable this by default but there are security considerations that we're working through.

As many have suggested before, it does not _need_ to be on by default, but it should be a simple toggle button, that could even show a confirmation dialog acknowledging the risk...but it should not be buried in documentation and only enabled via config.toml manually.

Like many, I spent the first few days working in Codex without web access because every time I asked Codex it claimed it was impossible...until I stumbled upon this issue using a Google search.

Taking a "secure by default" stance is a misnomer, for the lawyers or otherwise, but the product can absolutely make it more obvious and easier. We want to encourage more adoption of Codex and simplicity is key.

You can enable this feature by adding this to your config.toml file. [features] web_search_request = true We'd like to enable this by default but there are security considerations that we're working through. We generally take a "secure by default" approach with Codex. We need to be thoughtful about default-enabling features that have potential security ramifications.

We might as well treat web search the same way we treat modifying files or executing commands, as by requiring approval. This aligns with how Codex currently handles security concerns and also provides a better user experience. If everyone agrees with this, I’ll try to create a pull request to implement it.

Alternatively, web search could be enabled by default for directories where Codex is allowed to edit files and execute certain commands without approval.

I like that! All I want is --yolo to include web search on by default.

I think the main tension here is that we are papering a massive UX fail with security as an excuse. This is very ancient practice and we can buck this trend.

In tools like goose you can know an extension exists and also have the ability to use permissions to enable it.

Even if you didnt have a notion of building extensions being dynamically togglable you could add to the system prompt that the feature exists and can be enabled statically.

I dont understand why we feel it is ok to just say.. ok figure out by watching agent run python.. find this issue.. find the config and then restart your agent
.. that this is the UX solution. It is actually describing the UX fail in a way that shouldn't exist in any agent in 2026

Web search has been enabled by default. See this changelog post for more details.