Use HTTPeep CLI to Capture cURL, Node.js, Python, and Rust Requests

The Real Problem Is Often the Request You Never Saw

When an API issue stalls, the pain point is often not that the code is unreadable. It is that the real request was never observed.

You can add logs or interceptors, but both approaches have tradeoffs:

1. They usually require code changes.
2. They may show a transformed request instead of the original one.

For terminal-driven workflows, a simpler path is to open hp shell first, then start the tool or app you want to observe.

Start With hp shell

hp shell turns the current terminal into a capture environment for HTTPeep.

hp shell
next dev

That order matters. If you start next dev after entering hp shell, the Node process can inherit the proxy environment and its outgoing requests become observable in HTTPeep.

This is especially useful when you do not yet have a strong logging layer and you just want to see what actually leaves the process.

cURL: The Fastest Check

cURL is the simplest place to start.

hp shell
curl -i https://api.example.com/health

Then list sessions from another terminal:

hp sessions list --process-name-like curl

If you prefer a live stream:

hp monitor

cURL is good for checking whether the proxy path, certificate trust, and target host all look correct.

Node.js: Watch next dev

Node.js is where hp shell tends to pay off the most.

People often add request logs in interceptors, but that means:

• changing code,
• reading a modified request,
• and possibly missing what the process really sent.

If you only need to inspect next dev, this is enough:

hp shell
next dev

Then trigger a page render, API route, or server action and inspect the session:

hp sessions list --process-name-like node

The fields that usually matter most are:

• method
• url
• request headers
• request body
• status code
• timing

Python: Let the Process Inherit the Environment

Python tools such as requests, httpx, and aiohttp can also go through HTTPeep when they start inside hp shell.

hp shell
python app.py

If you prefer explicit proxy variables, that works too:

export HTTP_PROXY=http://127.0.0.1:8800
export HTTPS_PROXY=http://127.0.0.1:8800
python app.py

Then check the captured sessions:

hp sessions list --process-name-like python

Rust: Capture Requests Before the Process Starts

Rust CLI tools and services behave the same way. The main thing is to launch them inside the capture environment.

hp shell
cargo run

If the program reads proxy variables directly, you can set them before launch:

HTTP_PROXY=http://127.0.0.1:8800 HTTPS_PROXY=http://127.0.0.1:8800 cargo run

Then inspect the sessions:

hp sessions list --process-name-like cargo

What to Inspect in a Session

When a request is captured, look at the fields in this order:

1. method and url
2. headers
3. body
4. status code
5. timing

If you see a 401, check whether Authorization is actually present.

If you see a 500, verify that the payload is what you expected.

If you see a timeout, make sure the request truly reached the target environment.

Common Failure Modes

Only CONNECT Appears

That usually means HTTPS has not been decrypted yet. Confirm the local CA is trusted and retry the request.

The Proxy Does Not Seem to Work

Check whether the process was actually started from the shell that ran hp shell.

A Child Process Lost the Environment

Some launchers spawn a new process tree and drop proxy variables. In that case, verify the real request sender instead of the top-level launcher.

Bypass or Another Proxy Interferes

If the request is bypassed or rerouted elsewhere, HTTPeep cannot observe it. Check the path first, then the payload.

A Short Debugging Loop

The simplest loop is:

hp shell
next dev
hp sessions watch

or:

hp shell
cargo run
hp sessions list --process-name-like cargo

Let the real traffic enter the capture path first. Then inspect the session. Only after that should you go back to code.

Bottom Line

hp shell is not just another shell wrapper.

It is a way to observe terminal-originated traffic without first rewriting the code. For cURL, Node.js, Python, and Rust, that usually gets you to the real problem faster.