What happens to a proxy configured in the Postman app when the same collection is run from a terminal?

## The measured absence A terminal run of a saved Postman collection has **no command-line option for a proxy**. Not a misspelled one, not one that needs a different form — there is nothing to pass. A proxy the application was applying is configuration held by the application, and no argument transfers it. This is worth stating as an absence rather than as a gap in your memory, because the usual debugging move — search the help output for the flag, try a few spellings, assume you got the syntax wrong — is wasted effort here. The right conclusion after ten seconds is *there is no such flag*, and therefore the question becomes **what else can put a proxy in front of this process**. ## Why it surprises people The application was doing something for every call, quietly, that nobody had to think about: - Requests that reached an internal service through a proxy simply worked. - Nothing in the collection document ever mentioned a proxy, so nothing looked missing when it was exported. - The failure that follows is **not an assertion failure**. Calls fail to connect, or they connect to something entirely different, and the output reads like a broken network rather than a missing setting. The result is a classic "works on my machine" report where both machines are honest: the app run was proxied and the terminal run was not, and neither of them said so. ## What travels and what does not | Input | Reaches a terminal run? | How | |---|---|---| | Requests, folders, scripts, collection variables | Yes | inside the exported document | | A chosen environment of saved values | Yes | named as an argument | | A client certificate | Yes | a flag, though its entry is appended last with an `<all_urls>` match | | The application's proxy setting | **No** | there is no option that carries it | The certificate row is the useful contrast. Both are transport configuration the app applied for you; one has a command-line path with a precedence surprise, and the other has **no path at all**. Knowing which is which saves an afternoon. ## What that means on a build agent The practical consequences are all about where the run happens rather than what the command says: - A run on a machine that already reaches the target directly will pass, and the same command on a machine that needs a proxy will not — with no difference in the command itself. - Proxying, if it happens, is a property of **the environment the process was started in**, not of the collection and not of the arguments. - Because nothing declares the intent, a machine that quietly stops proxying produces the same symptom as a service that went down. ## How to handle it 1. **Establish reachability first, from the machine that will run the collection** — a plain request to the same host, before blaming the collection at all. 2. **Decide deliberately where proxying comes from** on that machine, and treat it as a property of the runner's environment that has to be set up, not as something the collection can carry. 3. **Do not spend time hunting for a flag.** Once you know the option does not exist, the search space collapses to the machine and its surroundings. 4. **Make the requirement visible** — a run that silently depends on being on a particular network is a run that will be debugged from scratch by the next person. ## The general lesson The interesting thing about this one is not the proxy. It is that **an implicit input with no explicit channel is the worst kind of handover**: an input you can pass badly at least tells you it exists, while an input with no argument at all leaves nothing in the command to review. When a collection moves from the application to a terminal, look for the inputs that have no representation on the command line, because those are the ones that will be discovered by failure rather than by reading.