How to Intercept and Edit a Request with Breakpoints on macOS

You have a hunch. One header is wrong, or the body is missing a field, or the backend returns a 401 where a 200 would make the screen render. You are fairly sure that changing that one thing fixes the bug — but proving it means editing code, rebuilding, and waiting for the app to come back up. Do that ten times while you narrow down the exact value and you have burned an afternoon.

There is a faster loop. Pause the real request while it is in flight, edit the field by hand, and let it continue. If the app recovers, your hypothesis holds and you know exactly what to change in the source. If it still fails, the problem is somewhere else and you have saved yourself a pointless rebuild. This guide walks through doing that with Rockxy Breakpoints on macOS — pausing a live HTTP request or response, editing the method, URL, headers, body, or status code, and sending the edited message onward.

What a Breakpoint actually does

A Breakpoint tells Rockxy to hold a matching message instead of passing it straight through. When a request matches, Rockxy freezes it before it reaches the server and opens the Breakpoint window with the message loaded into an editor. You change whatever you want — the URL, the method, a header value, the request body — then send the edited version upstream. One rule can also pause the response on its way back, so you can rewrite the status code and body before the client ever sees them.

That covers both directions of the classic "is it the client or the server?" question. Edit the outgoing request to test whether a corrected header fixes things, or rewrite the incoming response to test whether your client handles the success case at all. Nothing on disk changes, and the edit lasts exactly one message.

What you will need

• Rockxy on macOS 14 (Sonoma) or later — a native app you can grab from the Rockxy download page.
• Capture running, with the request you want to edit already appearing in the traffic list. If the row never shows up, fix routing first; the localhost capture guide covers the most common reason a local request skips the proxy.
• For an HTTPS target: the host must be inside Rockxy's SSL Proxying scope with certificate trust in place, or the message stays an encrypted tunnel with nothing to edit.
• The exact host, port, and path of the call you want to intercept. A Breakpoint only fires on messages its rule matches, so a precise match string is the difference between a pause and a no-op.

Step 1 — Turn the Breakpoint tool on

Open Breakpoint Rules from the Tools menu (or the toolbar icon). At the top of that window is an Enable Breakpoint Tool checkbox. Tick it. This is the switch developers miss most often: if it is off, Rockxy does not evaluate a single rule no matter how many you have created, and every request sails through as if no Breakpoint existed.

Leaving this checkbox on all the time is fine — with no rules defined, nothing pauses. It is the rules, not the master switch, that decide what gets caught.

Step 2 — Create a rule that matches your request

Click + in the Breakpoint Rules window to open the Breakpoint Rule Editor. The fields you care about:

• Name — a label for you, so a list of rules stays readable. Something like edit checkout headers.
• Matching Rule — the host, port, and path the rule applies to, for example api.example.com/v1/checkout. This is the field to get right; a trailing space or a stray http:// prefix is enough to make it never match.
• Method — restrict to POST, GET, and so on, or leave it at ANY to catch every verb on that path.
• Match Type — how the Matching Rule string is interpreted (exact versus wildcard). Use a wildcard when you want a whole path prefix; keep it exact when you want one specific endpoint and nothing else.
• Request and Response checkboxes — which side of the exchange to pause. Tick Request to edit the outgoing message, Response to rewrite what comes back, or both to stop on each side in turn. One rule covers both directions; you do not need a second rule for the response.

Save the rule. It should appear in the list with a tick in the Request and/or Response columns you selected. If it does not show up, the editor usually has a validation problem — an empty Matching Rule, or neither Request nor Response checked. At least one side has to be on.

Start narrow. A rule that matches one exact endpoint pauses only that call; a broad wildcard can freeze every request under a path and turn a quick edit into a queue of paused messages you have to clear one by one.

Step 3 — Trigger the request and edit it in flight

With the rule enabled, do the thing that fires the request — click the button in your app, run the script, refresh the page. Instead of completing, the call is held and the Breakpoint window opens with a banner reading "Request paused at breakpoint" and a live elapsed-time counter. The left sidebar lists the queued message with a REQ badge; the editor on the right is bound to it.

Now edit. The Method dropdown and the URL field are editable directly. Click the Headers tab for a two-column key/value table where you edit a value by clicking its cell and typing over it — this is where you fix a wrong Authorization token or a bad Content-Type. Click the Body tab to change the payload. When the edit is ready, click Execute in the action bar (or press ⌘↩) and Rockxy forwards the edited request upstream.

Step 4 — Rewrite the response (optional)

If your rule also ticked Response, the same message pauses a second time once the server answers — now on its way back to the client. The sidebar gains a row with a RES badge and the banner reads "Response paused at breakpoint". The action bar swaps the Method dropdown for a Status Code dropdown of preset HTTP codes, so you can turn a 401 into a 200 OK, then edit the Body tab to feed the client the shape you expect. Click Execute and Rockxy delivers the rewritten response as if the backend had sent it.

This is how you answer "does my client even handle the success case?" without touching the backend. Rewrite the response to the ideal payload; if the screen renders, the client is fine and the bug is upstream. If it still breaks on a clean 200, the fault is in your client-side handling.

The action bar

The buttons at the bottom of the Breakpoint editor decide how a paused message resolves:

• Execute (⌘↩) — sends the edited request upstream, or delivers the edited response to the client. The default, and the one you reach for most.
• Abort — resolves the paused message by returning an HTTP 503 to the client without contacting the server. Good for testing how your app handles an outage or a hard failure.
• Cancel (Esc) — dismisses the window while leaving the message queued, so you can step away and resolve it later.
• Templates — opens the Template Manager (covered next), for when you want to drop in a prepared message instead of hand-editing.

Reusing edits with templates

Typing the same corrected header or synthetic JSON body every time gets old. Open the Template Manager from the Window menu (Breakpoint Template) and you get two groups — Request Templates and Response Templates — seeded with two starters, JSON Request and JSON Response. Save your own, and in the Breakpoint editor you can apply a template to replace the message in one action rather than editing field by field. Templates persist across restarts, so a fix you use often is one click away next time.

If it does not work

The request completes normally and no window opens. The rule did not match. Check, in order: the Enable Breakpoint Tool checkbox at the top of Breakpoint Rules is ticked; the rule's own toggle is on; the Matching Rule string exactly matches the host, port, and path with no trailing space and no http:// prefix; and the request is actually being captured at all — if it never appears in the main traffic list, the client is bypassing the proxy and no Breakpoint can see it.

An earlier tool ate the request. Rockxy applies its rewriting tools in an order, and a request can be consumed before the Breakpoint stage sees it. If you also have an Allow List, Block List, Map Local, or Map Remote rule that touches the same path, one of those may be handling the request first. Disable the overlapping rule while you use the Breakpoint, or narrow it so the two do not collide.

The message pauses but the body is unreadable. That is TLS, not the Breakpoint. The host is not in SSL Proxying scope, or its certificate is not trusted, so you are looking at an encrypted tunnel with no editable body. Add the host to SSL Proxying scope and confirm certificate trust. If the target pins its certificate, Rockxy does not defeat that — a pinned or failed handshake is surfaced as a failed transaction in the traffic list rather than being decrypted, so you can see it happened.

Execute is greyed out. No message is selected in the sidebar. Click the queued row to bind the editor to it, then Execute becomes available.

The response side never fires. The rule's Response checkbox is off. Edit the rule and tick it; the request side pausing does not imply the response side will.

Where Breakpoints fit — and where they do not

Breakpoints are for interactive, one-off editing where you want to react to a live message and decide what to do with it in the moment. That interactivity is also the limit: every paused message waits for you, so a broad rule that catches dozens of requests turns into a stack of prompts. When you want the same edit applied silently to every matching request without pausing, a Rule that rewrites headers or maps a response is the better tool — no window, no waiting. And when you just want to fire an edited request repeatedly rather than intercept a live one, Replay lets you resend a captured call with modifications.

The rule of thumb: Breakpoints to discover the exact change that fixes a bug, then a persistent Rule or a code change to apply it.

Next steps

Editing one message in flight is the fastest way to test a fix before you commit to it. Enable the Breakpoint tool, write a tight matching rule, pause the call, change the field you suspect, and let it continue — the app tells you immediately whether you were right.

From here, the full Breakpoint reference and rule syntax live in the Breakpoints docs. For a longer worked example that pauses both the request and the response in one flow, see the auth-token case in the advanced API debugging guide. And if the request you want to edit never shows up in the first place, start with why localhost traffic is not captured — a Breakpoint can only pause a message Rockxy actually receives.