Safari Session Issues After Workflow Execution - Works in Chrome and Private Browsing

Hello …!!

Describe the problem/error/question

I’ve been using n8n for several months without any issues until last weekend. Now I’m experiencing a problem where I get disconnected from n8n every time a workflow executes, but only when using Safari in normal browsing mode. The same setup works perfectly in Chrome or when using Safari in private browsing mode.

After workflow execution, I’m unable to access the executions history and receive “Unauthorized” errors. The workflow itself executes correctly, but I can’t view the execution history or results in the n8n interface when using Safari (normal mode).

What is the error message (if any)?

In Safari console:
[Error] Failed to load resource: the server responded with a status of 401 () (executions, line 0)
[Error] Unhandled Promise Rejection: ResponseError: Unauthorized

In n8n logs:

2025-05-07T13:32:23.680Z | warn | browserId check failed on /rest/executions/ {"file":"auth.service.js","function":"resolveJwt"}
2025-05-07T13:32:23.684Z | warn | browserId check failed on /rest/executions/:id {"file":"auth.service.js","function":"resolveJwt"}

Please share your workflow

N/A - The issue occurs with any workflow. The workflows execute correctly, but I’m unable to view the execution history in Safari after execution.

Share the output returned by the last node

N/A - The workflows produce the expected output, but I can’t view them in Safari after execution.

Information on your n8n setup

  • n8n version: 1.91.1
  • Database (default: SQLite): SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main): Default
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker with Nginx reverse proxy
  • Operating system: Debian

Additional configuration details:

Docker-compose.yml:

version: '3'
services:
  n8n:
    image: n8nio/n8n:1.91.1
    container_name: n8n
    restart: unless-stopped
    environment:
      - N8N_HOST=***********
      - N8N_PORT=***
      - N8N_PROTOCOL=https
      - N8N_SECURE_COOKIE=false
      - N8N_USER_ALLOWED_EMAIL_DOMAINS=************
      - N8N_USER_ALLOW_NEW_REGISTRATIONS=false
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=*********
      - N8N_BASIC_AUTH_PASSWORD=**********
      - WEBHOOK_TUNNEL_URL=https://********
      - WEBHOOK_URL=https://********
      - N8N_CUSTOM_EXTENSIONS_ENABLED=true
      - N8N_TRUST_PROXY=1
      - N8N_LOG_LEVEL=debug
      - N8N_DISABLE_BROWSER_ID_CHECK=true
      - N8N_DISABLE_RATE_LIMIT=true
    volumes:
      - ./n8n_data:/home/node/.n8n
      - /home/debian/docker/n8n/files:/files
    networks:
      - proxy

networks:
  proxy:
    external: true

Nginx configuration:

server {
    listen 443 ssl http2;
    server_name ********

    ssl_certificate /etc/letsencrypt/******
    ssl_certificate_key /etc/letsencrypt/******

    location / {
        proxy_pass http://n8n:***;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # WebSockets config
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

I’ve tried several solutions including:

  1. Setting N8N_SECURE_COOKIE=false
  2. Setting N8N_TRUST_PROXY=true
  3. Adding N8N_DISABLE_BROWSER_ID_CHECK=true
  4. Various Nginx header configurations
  5. Completely resetting the n8n installation

None of these solutions fixed the issue in Safari, though Chrome works fine, and Safari in private mode also works.

Additional evidence and hypothesis: I’ve analyzed Safari’s console logs and found numerous 401 Unauthorized errors after executing a workflow, confirming that Safari loses its authentication state. The logs show that Safari generates anonymousId and userId values correctly, but subsequent API requests fail with 401 errors.

Looking at Safari’s behavior specifically, its Intelligent Tracking Prevention (ITP) and strict cookie policies appear to be interfering with n8n’s JWT token handling. Safari’s privacy features might be blocking or modifying the authentication cookies between requests, especially after workflow execution that triggers redirects or state changes.

This explains why:

  1. Chrome works fine (less restrictive cookie policies)
  2. Safari in private mode works (fresh session with fewer privacy restrictions applied)
  3. The problem appeared recently (possibly after a Safari update)

Version information from logs: Safari 18.4 on macOS Sonoma 15.4.1 (24E263) with n8n 1.91.1

no one as an idéa?