History and the activity panel

Every send that produced a response writes one .http file to requests/.runs/. A send that never reached its server — an unreachable host, a refused connection, an expired timeout — has no response to record and writes no entry; the reason is shown on the request itself instead.

The file name encodes the timestamp, a short disambiguator derived from the run id, the method, and a slugified URL: 20260515T142304123Z-3f7a-POST-auth_login.http.

The content is real .http text you can open in the editor: a block of # @ metadata directives (timestamp, run id, source file, duration, resolved settings) at the top, the request as it went on the wire, the line ### Response, the response, and — when there are logs or assertions — a # @script-results: … block at the end. Each entry records:

• The request that went on the wire (method, URL, headers, body) after variable interpolation, with the cookies effectively attached visible in the Cookie: header.
• The response (status, headers, body, timing) with Set-Cookie: headers preserved verbatim.
• The link back to the source .http file and the request’s stable UUID.
• Script results — logs, pass/fail tests, and a filtered stack trace for top-level errors — for both phases, when present.
• The resolved HTTP settings actually used for the send.

Binary bodies — detected by Content-Type prefix, a Content-Encoding other than identity, or a UTF-8 probe of the first 1 KB — are replaced by a placeholder line recording the byte count, content type, and content encoding. This keeps the file human-scannable and prevents non-text bytes from corrupting the editor view.

The Activity Panel

The Activity Panel is a full-width panel that emerges from the bottom of the window. It is opt-in: it always starts closed on launch and is toggled with a status-bar button or Cmd/Ctrl+J (also View → Toggle Activity Panel). It overlays the editor and response viewer but never covers the status bar, so the toggle stays visible.

The panel is organised by tabs, one per activity kind. v1 ships a single Requests tab that lists records for the currently active request. Clicking a row expands it in place — several rows can be expanded at once — into a structured viewer for that run; right-clicking exposes “Open” (a read-only tab), “Raw .http” (the file content verbatim), and “Delete”; a small repeat icon re-runs the request.

The expanded view shows a Metadata key/value table (source file with an “Open file” affordance, run id, request id, duration, status, remote IP, timestamp in local time, and one row per resolved HTTP setting), the raw Request and Response exactly as stored, and — when the run produced script content — a Scripts section listing logs and pass/fail assertions in execution order, grouped by phase (Pre-request / Post-response). When the response Content-Type is JSON, a per-row Format toggle pretty-prints the body without affecting the headers or any other row.

The tab strip is the surface where future activity kinds (mocks, flows, OAuth flows) will land as additional tabs without restructuring the sidebar.

You resize the panel by dragging its top edge, and the height is remembered across sessions (open/closed and popout state are not). On first run it opens at roughly half the window height, clamped so the editor and status bar still have room.

The panel can also be popped out into its own minimal window — useful for dual-monitor setups. While popped out, the docked panel disappears and the status-bar toggle or shortcut focuses the popout instead of opening a duplicate; closing the popout (or clicking “dock back”) returns the panel to its in-window location. The popout window is not restored on app restart.