A search query is another disclosure. This diagram shows the route OpenAI describes, not a capture of a particular user's traffic.
ChatGPT Search can send rewritten questions to other search companies. Relevant saved memories can help shape those questions. OpenAI says it doesn't send your ChatGPT account information or your IP address to those partners, but the words in a query can be sensitive on their own. Before I let an AI research something confidential, I want to know what it's about to ask, and who gets to read it.
What does ChatGPT share with search providers?
OpenAI's search documentation (opens in new tab) describes a process with several steps. ChatGPT can decide that a question needs current information, rewrite it into targeted queries, send those to a search partner, and then search again after reading the first results.
That gives the assistant considerable discretion. I type a conversational request; it chooses the terms that leave the chat. OpenAI links Microsoft and Shopify's privacy policies for how its search providers process queries.
The saved-memory paragraph is easy to miss. Information from an earlier conversation can help shape a new search.
The company's example is benign: someone who has mentioned being vegan and living in San Francisco asks for nearby restaurants. ChatGPT can use those remembered preferences in the search. That's useful. It also means the question I just typed isn't the complete list of information that can influence the query.
Imagine I'm comparing analytics databases for an acquisition. I explain the deal, the customer base, the budget, and the deadline, then ask the assistant to find vendors with EU hosting.
The public research needs terms such as analytics database EU hosting. The acquisition target,
offer price, and internal project name add nothing to that lookup. I'd remove them before asking a
search engine. When the AI writes the query, I want the same chance to make that decision.
Removing account identifiers helps, but it can't make the query's own contents harmless. An unannounced product name or a distinctive description of a customer incident can reveal what a company is doing without naming the person who asked.
ChatGPT's search activity didn't show me the exact queries
I checked the web interface on November 9, 2026, using GPT-5.6 Sol at Medium effort in an Unpersonalized Temporary Chat. I asked it to find three senior product manager jobs in Reno, with links to employer pages. The first response's expanded activity said it had searched nine websites. A repeat of the same request showed 17.
In both, I could read the answer and its source links. I couldn't see the exact outgoing search queries in the expanded activity. Clicking the repeat's "Searched 17 websites" line didn't reveal them either.
The activity explains the task and counts websites. It doesn't show the query text I wanted to inspect.
A citation tells me where an answer came from. A query tells me what information went out to get it. An ordinary employer link at the end of a search wouldn't tell me whether an unnecessary detail appeared in an earlier query.
For developers, OpenAI's web-search API guide (opens in new tab) makes the distinction explicit: a search-call action and the answer's URL citations are separate output. Search actions usually include query text, though OpenAI says they don't always include it. A product that displays citations hasn't necessarily given you a query audit trail.
Temporary Chat can still search, and it can still use memories
The job search above ran in a Temporary Chat. Keeping a conversation out of history and model training didn't stop it searching the web.
There's another choice inside Temporary Chat: Personalized or Unpersonalized. In the current interface, Personalized can reference existing memories, plugins, and custom instructions. Unpersonalized ignores them. Neither creates or updates memories while the chat remains temporary, according to OpenAI's guide (opens in new tab).
Choose before sending the first message. A temporary conversation can still draw on things you've told ChatGPT before.
Unpersonalized is the better starting point when I want a public lookup separated from earlier conversations. I still have to leave private details out of the new prompt. The setting can't remove something I've just typed into that very chat.
Location has a similar distinction. Turning off device location sharing stops that optional source of location. OpenAI can still estimate a general location from the connection's IP address and use it for local results. The search guide says that general location can reach a partner, while the IP address itself is withheld. Moving from the website to the Mac or iPhone version doesn't, by itself, remove this search-provider handoff; OpenAI offers Search across web, desktop, and mobile.
The practical controls cover different jobs:
| Choice | What it changes | What still needs attention |
|---|---|---|
Temporary Chat | History and training treatment while the chat stays temporary | Search can still run. |
Unpersonalized Temporary Chat | Existing memory, custom instructions, and plugins aren't used | The current prompt can still contain private information. |
Device location sharing off | Removes optional device-provided location | IP-derived general location can still influence search. |
Search disabled by a managed workspace or role | Blocks ChatGPT web search for affected users | Other tools and third-party GPTs need their own controls. |
I've covered what happens to deleted chats and retained copies separately. Here the decision comes earlier: which information should leave through a search tool in the first place?
Some ChatGPT workspaces can search cached pages instead
OpenAI offers a more substantial boundary for some managed workspaces. Offline web search uses OpenAI's indexed and cached pages rather than live external web search at request time. It gives an organization a way to keep web research useful while limiting live search-provider queries.
"Offline" refers to the source of search results. The conversation still goes to OpenAI.
This isn't a universal consumer switch. OpenAI's workspace guide (opens in new tab) lists eligible configurations, including certain Enterprise, Edu, Healthcare, Teachers, regulated, and federal workspaces. Setup can involve a Lockdown Mode role or configuration by OpenAI. Admins need to confirm the arrangement for their workspace.
The tradeoff is freshness and coverage. A page can be missing, stale, or impossible to retrieve at a specific URL. OpenAI doesn't promise a refresh deadline for each page. That's a reasonable trade for some background research; it's a poor fit for checking whether a filing changed this morning.
Enterprise and Edu admins also have a Web search setting and role controls (opens in new tab) that can disable search. The workspace setting covers ChatGPT and GPTs created inside that workspace, not third-party GPTs. Other connected tools have their own permissions. I'd ask an admin which outbound routes remain enabled, rather than infer the answer from the workspace's name.
API developers have a separate live-access control
The Responses API's web_search tool supports external_web_access: false for cached-only results.
Live access is the default when that parameter is omitted. There's an important compatibility catch:
the older web_search_preview tool ignores this parameter and continues to behave as though live
access is enabled, according to the
API guide (opens in new tab).
The developer has to configure that API control. It isn't a setting in the consumer ChatGPT interface.
Separate public web research from private analysis
My preferred workflow is simple enough to use without trusting the assistant to recognize every sensitive detail.
- Search with public context only. Start a separate, unpersonalized conversation. Describe the public question without the customer name, internal hostname, deal price, or private document.
- Read the sources. Check the pages that matter, then keep the public excerpts and links you need. Review generated query text too if your product exposes it.
- Do the private analysis with outbound tools disabled. Use a product or workspace that lets you disable web search and other external tools. Bring in the reviewed public sources, then add only the private material you're authorized to send to the selected AI provider.
The private notes join after public research. Disabling tools limits additional destinations; it doesn't keep a cloud model from receiving the analysis.
OpenAI recommends the same separation to API developers using private records: run public web search and private MCP lookups in separate requests (opens in new tab).
Asking "don't search without checking with me" is a useful instruction. I'd still want an enforced tool control for confidential work. Otherwise, I'm relying on the same model that decides what to search to also remember when it shouldn't.
How I control search tools in Cumbersome
I build Cumbersome, our AI client for iPhone and Mac. Its Local Browser tools show search and page-reading activity, including the query and the engine that returned results. The device contacts the engine or website directly, without a Folding Sky search proxy. The engine gets the query; the selected AI provider gets snippets or extracted page text.
That visibility helps me inspect a search. It doesn't give me approval before each one. Cumbersome currently runs generated queries automatically when those tools are enabled, and a fallback can send the same query to another engine. I don't want to sell local browsing as a promise that queries stay on the device.
When I need to review each query before sending it, I turn off Local Web Search and Provider Web Search, search manually, and check which other browser or remote tools are enabled. I can then bring the public material back into the conversation and use the model I want for the analysis.
If a query is going to tell another company what I'm working on, I want to write it myself.
Bless up! 🙏✨