How to Copy Any Captured Request as cURL on macOS

You captured a request in your macOS debugger, and now you need to reproduce it somewhere else — in a terminal, in a bug report, or inside a script. The slow way is to hand-copy the method, every header, and the body, then hope you did not typo a token or drop a field. The fast way is to let the proxy write the curl command for you.

Rockxy does exactly that. Select any captured flow, choose Copy as cURL, and you get a ready-to-run curl command with the method, all request headers, and the body already filled in. The outcome of this guide is a command you can paste into a terminal or a ticket and have it fire the exact same request — same URL, same headers, same payload — no hand transcription.

Why copy a request as cURL

A captured flow lives inside Rockxy. A curl command lives anywhere. Turning one into the other is useful in three recurring situations:

1. Reproduce on the command line. You want to re-run a request outside the app, tweak a header, or loop it in a shell — without rebuilding it by hand from the inspector.
2. File a precise bug report. Instead of describing "the POST to the orders endpoint," you paste the actual command. Whoever picks up the ticket runs the same request and sees the same failure.
3. Drop it into a script. A copied curl is a starting point for a smoke test, a cron job, or a one-off automation, with the real headers already in place.

Note the direction. Rockxy exports a captured request as curl. It does not import a curl command back in — if you want to edit and re-fire a request inside Rockxy, that is what Compose and Replay are for, covered near the end.

What you will need

• Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
• At least one captured flow in the traffic list — any request Rockxy has already recorded. If the list is empty, send a request through the proxy first.
• A terminal, so you can paste and run the copied command.
• A moment of care around secrets: a copied command carries whatever auth the request used. More on that below before you share anything.

Step 1 — Select the flow you want to reproduce

Open Rockxy and find the request in the traffic list. Use filters or search to narrow it down if the list is busy — by host, method, or status. Click the row so the flow is selected and its detail opens. This is the request that will become the curl command, so make sure it is the one that actually reproduces the behavior you care about, not a similar-looking neighbor.

What you should see in Rockxy: the selected flow's request line — method, URL, and status — along with its request headers and body. That is the full set of data Copy as cURL will encode, so if it looks complete here, the command will be complete too.

Step 2 — Copy the request as cURL

With the flow selected, use Copy as cURL to place the command on your clipboard. Rockxy assembles the method, the request headers, and the body into a single curl invocation. If you are unsure exactly where the action sits in your build of the app, the traffic-capture and export behavior is documented in the traffic capture docs.

The copied command has the shape below. This is representative — your host, path, headers, and body will match the flow you selected:

curl 'https://api.example.com/v1/orders' \
  -X POST \
  -H 'Authorization: Bearer eyJhbGciOi...redacted...' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  --data-raw '{"sku":"RX-42","quantity":2}'

Everything the server needs to receive the same request is here: the method after -X, each header after its own -H, and the payload after --data-raw. A GET with no body simply omits the last two lines.

Step 3 — Redact secrets before it leaves your machine

Read the command before it goes anywhere. That Authorization header, any Cookie, and any API key are all live credentials, copied verbatim. Pasting that into a public issue, a shared channel, or a screenshot leaks a working token to everyone who can read it.

So before you share: replace the secret values with obvious placeholders like Bearer <TOKEN>, and drop cookies you do not need for the repro. Keep the header names — they show the shape of the request — while removing the values. If you find yourself doing this on every share, the dedicated walkthrough in Redact secrets before sharing a capture on macOS covers the full checklist.

Step 4 — Verify the command reproduces the request

Paste the command into a terminal and run it. A copied curl should return the same status and shape of response as the original flow — allowing for anything genuinely time-sensitive, like a short-lived token or a one-time nonce.

One thing to keep in mind: a curl run outside the proxy will not appear back in Rockxy. If you also want the reproduced request captured, route it through the proxy port explicitly — the mechanics are the same as any loopback or direct request, and are covered in Why localhost traffic isn't showing in your proxy on macOS. For a quick standalone check, running it directly is fine; you are confirming the request, not re-capturing it.

Re-running an edited request inside Rockxy

If your goal is not the command line but to change the request and fire it again inside the app, do not reach for curl — Rockxy does not accept a pasted curl command as input. Use the built-in tools instead:

• Replay re-sends the captured request as-is, so you can watch it run again through the proxy.
• Compose lets you edit a request — change a header, a query param, or the body — and send it, with the result captured like any other flow.

The end-to-end version of that loop, including how to iterate on a failing call, is in How to replay a failed API request on macOS. Keep the two directions straight: curl for leaving the app, Compose and Replay for staying in it.

If it does not work

The command returns a different status than the capture. Most often a credential has expired. Bearer tokens, session cookies, and CSRF values are frequently short-lived, so a command copied minutes ago may already be stale. Capture a fresh flow and copy that one.

The body looks garbled or truncated. Binary or compressed payloads do not always round-trip cleanly as a literal --data-raw string. For those, reproduce from the original flow with Replay rather than a hand-run command, and inspect the decoded body in Rockxy directly.

The reproduced request never shows up in Rockxy. That is expected — a plain curl run does not go through the proxy unless you point it there. Add the proxy explicitly if you want it captured; see the loopback guide linked above.

You are worried a token slipped out. If you shared a command before redacting, treat the token as compromised and rotate it. Then make redaction a habit before the copy leaves your machine, not after.

Limitations to know

• Export only. Copy as cURL is one-directional. Rockxy writes a curl command from a captured flow; it does not read a curl command back in. Use Compose and Replay to build or re-run requests in the app.
• The command contains real credentials. Auth headers and cookies are copied as-is. Always redact before pasting into anything shared.
• A curl run outside the proxy is invisible to Rockxy. Route it through the proxy port if you need the reproduced request captured too.
• macOS only. Rockxy is a native macOS app; the Copy as cURL workflow lives inside it.

Next steps

The rule is short: pick a flow, Copy as cURL, redact, verify. A captured request becomes a portable command you can run in a terminal, attach to a ticket, or seed a script with — no hand transcription and no dropped headers.

From here, learn to replay a failed API request when you need to iterate inside the app, tighten your secret redaction before sharing, or make sure your local calls are captured in the first place with the loopback guide. The full capture and export reference lives in the Rockxy docs.