Share Your Browser Session with curl: The Session Capture/Replay Feature in Fluxzy

You've just logged into a web application through your browser, and now you need to hit some authenticated API endpoints using curl or another command-line tool. What follows is usually a tedious dance: open DevTools, find the right cookies, copy them carefully, paste them into your terminal, and hope you didn't miss anything. If the session refreshes? Start over.

What if your CLI tools could simply inherit your browser's authenticated session automatically?

That's exactly what Fluxzy's Session Capture/Replay feature does. By routing both your browser and CLI tools through the same proxy, Fluxzy captures authentication data from one client and seamlessly applies it to requests from others. No more copy-pasting tokens. No more expired cookie frustration. Just authenticate once in your browser, then use any HTTP client as if it were already logged in.

In this article, I'll walk you through how this feature works, how to set it up, and share some practical examples you can reproduce on your own machine.

---

The concept is straightforward: Fluxzy acts as a man-in-the-middle proxy that maintains a shared session store.

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Browser   │────▶│   Fluxzy    │────▶│   Server    │
│  (login)    │◀────│   Proxy     │◀────│  (github)   │
└─────────────┘     │             │     └─────────────┘
                    │  Session    │
                    │   Store     │
┌─────────────┐     │  ┌───────┐  │
│    curl     │────▶│  │cookies│  │
│  (API call) │◀────│  │headers│  │
└─────────────┘     │  └───────┘  │
                    └─────────────┘

Here's the flow:

1. Capture phase: When a server responds with Set-Cookie headers or other authentication headers, the CaptureSessionAction intercepts and stores them, organized by domain.

2. Storage: Session data lives in memory, isolated per domain to prevent cross-site leakage.

3. Replay phase: When any client makes a request to a matching domain, the ApplySessionAction automatically injects the stored session data into the outgoing request.

4. Shared access: All clients routing through the proxy share the same session store, meaning your curl commands benefit from your browser's authentication.

---

Fluxzy uses YAML rule files to configure its behavior. Create a file named session-rules.yaml with the following content:

rules:
  # Capture session from all github.com responses
  - filter:
      typeKind: HostFilter
      pattern: "*.github.com"
    actions:
      - typeKind: CaptureSessionAction
        captureCookies: true
        captureHeaders:
          - Authorization
          - X-CSRF-Token

  # Apply session to requests with curl user-agent
  - filter:
      typeKind: RequestHeaderFilter
      headerName: User-Agent
      pattern: "*curl*"
    actions:
      - typeKind: ApplySessionAction
        applyCookies: true
        applyHeaders: true
        mergeWithExisting: true

This configuration tells Fluxzy to capture cookies and specific headers from any GitHub response, then apply them to subsequent GitHub requests.

Launch the proxy with your rule file:

fluxzy start -l 127.0.0.1:8080 -r session-rules.yaml

Set your browser to use 127.0.0.1:8080 as its HTTP/HTTPS proxy. Most browsers allow this in their network settings, or you can use a proxy-switching extension for convenience.

Navigate to github.com in your browser and log in as you normally would. Fluxzy silently captures the session cookies in the background.

Now the magic happens. Run a curl command through the proxy:

curl -x 127.0.0.1:8080 https://api.github.com/user

Without any manual cookie handling, this returns your authenticated user data. Fluxzy automatically injected the session cookies captured from your browser.

---

Controls what gets captured from server responses.

Property	Type	Default	Description
captureCookies	bool	true	Capture cookies from Set-Cookie headers
captureHeaders	string[]	[]	Header names to capture, e.g., ["Authorization"]

Controls what gets injected into outgoing requests.

Property	Type	Default	Description
applyCookies	bool	true	Apply stored cookies to requests
applyHeaders	bool	true	Apply stored headers to requests
mergeWithExisting	bool	true	Merge with client's existing cookies (vs replace entirely)
sourceDomain	string	null	Use session from a different domain (useful for subdomains)

Allows programmatic session clearing.

Property	Type	Default	Description
domain	string	null	Domain to clear (null clears all sessions)

---

Many applications use a main domain for authentication but serve APIs from a subdomain. You can configure Fluxzy to share sessions across them:

rules:
  # Capture from main domain
  - filter:
      typeKind: HostFilter
      pattern: "example.com"
    actions:
      - typeKind: CaptureSessionAction
        captureCookies: true

  # Apply to API subdomain using parent domain session
  - filter:
      typeKind: HostFilter
      pattern: "api.example.com"
    actions:
      - typeKind: ApplySessionAction
        applyCookies: true
        sourceDomain: "example.com"

Sometimes the Authorization header is set by the client (perhaps via a browser extension) rather than received from the server. Fluxzy can capture these too:

rules:
  - filter:
      typeKind: HostFilter
      pattern: "api.example.com"
    actions:
      - typeKind: CaptureSessionAction
        captureCookies: true
        captureHeaders:
          - Authorization

You can trigger a session clear when hitting specific paths:

rules:
  - filter:
      typeKind: PathFilter
      pattern: "/logout"
    actions:
      - typeKind: ClearSessionAction
        domain: "github.com"

By default, captured cookies merge with any cookies the client already provides. If you want the captured session to completely override client cookies:

rules:
  - filter:
      typeKind: HostFilter
      pattern: "example.com"
    actions:
      - typeKind: ApplySessionAction
        applyCookies: true
        mergeWithExisting: false

---

• Eliminates copy-paste workflows: No more hunting through DevTools for cookies and tokens.
• Works with any HTTP client: curl, wget, httpie, custom scripts—anything that can use a proxy.
• Real-time session updates: Token refreshes and new cookies are captured automatically.
• Domain isolation: Sessions are strictly separated by domain, preventing accidental cross-site leakage.
• Thread-safe: Concurrent requests from multiple clients are handled correctly.

• Security-sensitive: Session data is stored in memory. Anyone with access to the proxy can use captured sessions.
• No persistence: Sessions are intentionally lost when the proxy restarts (a security feature, not a bug).
• Local network only: This only works for clients routing through the proxy on the same machine or network.
• Cookie scope simplification: Path-scoped cookies may be applied more broadly than the server intended.

---

This feature is designed for development and testing environments. Keep these points in mind:

1. Never expose the proxy to untrusted networks. Anyone who can route through your proxy gains access to captured sessions.

2. Sessions are memory-only. By design, nothing persists to disk, reducing the risk of session data being recovered later.

3. Sessions clear on restart. Stopping Fluxzy wipes the session store.

4. Domain isolation is enforced. A captured session for github.com will never leak to gitlab.com.

---

The Session Capture/Replay feature transforms Fluxzy from a debugging proxy into a session-sharing hub. Whether you're testing authenticated APIs, automating workflows that normally require browser sessions, or just tired of copying cookies around, this feature can save you significant time.

Set up takes just a few minutes: create a rule file, start the proxy, authenticate in your browser, and your CLI tools are ready to go. Give it a try on your next project and see how much friction it removes from your workflow.