Reuse a CamoFox Browser Session Across n8n HTTP Nodes

Quick answer: Let n8n coordinate the workflow while CamoFox Browser keeps the browser state. Create one task tab, retain its userId, sessionKey and returned tabId, and send later HTTP requests to that same tab. Check that the report page is actually authenticated, extract the expected fields, then close only the tab you own and verify it has disappeared.

This pattern is useful when an owned or explicitly authorized reporting portal has no suitable export or supported API. It does not require CamoFox MCP, an official n8n community node, or an AI model. If the portal already offers a reliable export/API, start there instead.

Controlled validation — 5 October 2026: we executed the same-tab lifecycle twice through real n8n HTTP nodes against an owned synthetic report, then tested an expired-session branch that cleaned up and stopped. This validates the local session pattern, not access to your real portal, report export or email delivery. The compatible engine was confined to the fixture lab, not recommended for production; exact versions and the earlier incompatible-stack failure are recorded below.

Why a multi-step browser workflow can lose its login

An HTTP Request node is an API client, not a browser context. If each node starts a fresh browser or creates a different user context, the next step may receive an empty tab or a sign-in page rather than the report you expected. A real n8n discussion describes this problem when separate Puppeteer nodes did not share context.

CamoFox provides a browser server that can be called through REST. Your workflow sends actions to the server; cookies and the rendered page belong to its browser context. Reusing the right identifiers is what connects the steps. It does not make an expired or revoked portal login valid again.

Know which state you are preserving

The Browser profile documentation explains its persistent contexts. Use a dedicated authorized profile for this job, rather than a personal profile with unrelated accounts.

A task label is not an account-isolation boundary. At the linked source, default contexts are user-scoped; an existing-tab navigation checks userId and tabId, not a caller-supplied sessionKey. Store the task/session label in n8n and verify the expected task-to-tab mapping before sending an action. Do not assume that adding a different session key will make the server reject a mismatched task. Keep different authorized identities in their dedicated user/profile scope, and do not treat a caller-selected identifier as permission to use another identity.

Before connecting n8n: check two different network paths

Path one is n8n → CamoFox Browser. The HTTP node needs a reachable service address and the authentication required by that server. Inside a Docker container, localhost means that container, not automatically the host or another service. Use a route approved for your deployment, such as the Browser service name within an appropriately configured private network. n8n's HTTP Request troubleshooting guide distinguishes connection-refused errors and container routing.

Path two is CamoFox Browser → the reporting portal. A successful connection to the Browser API does not prove that navigation to your private portal is allowed. The documented Browser defaults bind to loopback; exposed configurations require API authentication and restrict private navigation targets by default. Review the exact security defaults with the person responsible for your network. Stop for an approved configuration rather than disabling authentication or target protections to make a demo work.

n8n Cloud cannot reach a service bound only to your laptop's loopback address. Moving this pattern to the cloud is a separate deployment decision, not a reason to expose an unauthenticated browser server.

Build the workflow around one task context

For a first run, use a synthetic report on a site you control. The example identity below is fictional. Replace the Browser base URL with your approved reachable address; do not paste actual portal credentials into the request body or exported workflow.

1. Create the task tab and retain its response

In an n8n HTTP Request node named Create tab, choose POST, set the URL to your Browser base URL plus /tabs, enable Send Body and choose JSON. Configure API authentication through n8n's credential mechanism if your Browser deployment requires it.

{
  "userId": "reports-demo",
  "sessionKey": "monthly-report",
  "url": "https://portal.example.test/reports"
}

portal.example.test is an illustrative address, not a live demo or service. Retain the actual returned tabId alongside your chosen userId and sessionKey. For the node's response, choose JSON and leave Include Response Headers and Status off for a body-only response. If you enable it, the body is wrapped and later field mappings must use that structure instead.

Do not create another tab just because the next node needs a page. A fresh tab is a different target, and accidentally changing userId can select a different context.

2. Navigate the existing tab, then inspect the page

Configure the next node to POST to /tabs/<tabId>/navigate, using the identifier from Create tab. Its JSON body contains the same userId and the authorized report URL:

{
  "userId": "reports-demo",
  "url": "https://portal.example.test/reports"
}

With the body-only response configuration described above, the tab portion of an n8n URL expression can use {{ $('Create tab').item.json.tabId }}. Confirm the actual output field before adapting the expression; do not map a sample tab ID into a real workflow.

Read the snapshot at GET /tabs/<tabId>/snapshot?userId=reports-demo. Check the resolved page, the report heading and a known authenticated-only field. A successful HTTP response from the Browser server is not proof that the portal signed you in: the visible page may still be a login or permission-denied screen.

If sign-in is needed, use an approved human or credential flow on the dedicated profile. Stop on MFA, unexpected account identity or expired access. This tutorial is not a way to bypass those controls.

3. Extract the report only after it is ready

Use the documented wait action and inspect the report's actual readiness condition. Then call the structured extraction endpoint on the same tab. Define the fields that make the report useful: for example report heading, period and rows. Mark fields required when their absence makes the report unusable. For the complete schema language, use the structured-extract reference.

Keep the captured source URL, capture time and completeness outcome with the data. Converting that JSON into CSV, emailing a report or scheduling a recurring run is additional n8n/workflow logic; it is not automatically included because the browser extraction succeeded.

4. Close the owned tab and read back the result

Send DELETE /tabs/<tabId> with the JSON body {"userId":"reports-demo"}. Then list GET /tabs?userId=reports-demo and confirm the exact owned tab is absent. Build a cleanup path for both normal completion and failure; do not rely solely on the final happy-path node.

This readback matters because the documented delete operation is idempotent: a successful delete response can mean no matching tab was found in the specified user scope. If you passed the wrong user, that response alone does not prove the real tab was closed. Do not reset every session as a shortcut; another task may still be using it.

A practical error-and-stop table

What the executed n8n example actually did

Each of the two successful CLI runs executed Manual → Create tab → NavigateOne → SnapshotOne → NavigateTwo → SnapshotTwo → Close owned tab → VerifyList. The two report snapshots used the same returned tab ID within that run and visibly contained Synthetic operations report, Authenticated fixture and Open orders: 3. The second complete run received a distinct new tab. Both n8n's list result and a separate Browser API readback were empty after cleanup. The fixture contains no report period, currency or revenue field; none is inferred.

In the separate expiry test, the same tab first showed the authenticated report. After the fixture's session-expiry action, the report page instead showed Authentication expired or missing and STOP: approved re-authentication required. The n8n If node sent one item down its false branch and none down the true branch. The false branch closed the tab, verified absence and stopped. The report-extraction node and disabled business-send sentinel did not execute; no actual sending service was configured. A real portal needs its own URL, account and authenticated-state checks, not a universal check for the word “authenticated”.

n8n's HTTP Request documentation covers JSON bodies, response options and importing cURL. Keep Never Error off unless you have a deliberate branch that inspects status and content. Do not enable blind retries on submissions, purchases, deletes or other actions whose first outcome is uncertain.

Repeat runs and restarts are different checks

Run the synthetic report twice and confirm you did not leave duplicate tabs. Separately test a controlled Browser restart with the configured profile directory preserved. Browser storage and an active tab are different: recreate a controlled tab after restart and verify the portal still accepts the profile. Never promise that a specific live tab, login or portal session survives indefinitely.

If your existing Playwright workflow already handles this well, you do not need to replace it. Choose this REST pattern when having one browser-state owner behind several workflow steps makes the job easier to operate.

Your next useful test

For the product overview, see CamoFox Browser. The concrete next step is a dedicated test report, not connecting a real portal before its access and network policy are understood.

Create one dedicated task with the documented CamoFox Browser API, retrieve one authorized report and verify cleanup before adapting it to real operations. Windows readers can use our Browser-versus-MCP setup guide. If an AI client is part of your later workflow, see the separate MCP architecture; it is optional for the HTTP-node pattern here.

Method and scope

Auto-Bot.io publishes this guide using redf0x1/camofox-browser, not the separate same-named jo-inc repository. The controlled runs used unpatched Browser v2.4.8 (Preview), commit 4f23dcf30dc0a1fb20b1a94fd6035a000a31a8bd, camoufox-js 0.8.5, Browser Node 22.22.2, n8n 2.41.6 on Node 24.18.0, and official Camoufox 135.0.1 beta.24 in a dedicated macOS fixture environment. The older engine's age/security was not assessed: this is not a recommendation to downgrade or expose a production browser.

An earlier isolated engine pair, Camoufox 156.0.1 beta.34 with the same Browser/SDK, failed before tab creation with HTTP 500 Unknown property navigator.product in config. That failed run is retained, not rewritten as success. Run a compatibility preflight before using your own approved deployment; do not disable protections or strip fingerprint properties to make the example pass.

The evidence is synthetic n8n CLI integration, not the n8n editor UI, cloud/container networking, a live portal login, browser restart/profile persistence, structured report export, CSV/email delivery or generic HTTP-error cleanup. Browser supplies the service; n8n supplies orchestration. This is not an official n8n integration or a turnkey production workflow. The hero is an editorial illustration, not an n8n screenshot.