Pwnbox (HTB) tab gets suspended/minimized in Brave on Kali Linux — how to fully prevent it?

Brave Browser
1

Brave developers care to explain or provide a proper solution for this issue.

I am using Brave Browser on Kali Linux and accessing Hack The Box Pwnbox (browser-based remote VM).

Problem:

Whenever I leave the Pwnbox tab inactive or switch tabs, Brave seems to throttle, suspend, or effectively “minimize” the session. This causes:

  • Input lag / frozen VM screen

  • Disconnected or stalled remote session

  • Broken workflow during labs

What I already tried (none worked):

  • Disabled Memory Saver

  • Disabled Energy Saver

  • Disabled tab discarding via brave://discards

  • Pinned the Pwnbox tab

  • Kept the window active (still gets affected sometimes)

  • Checked brave://flags and disabled window occlusion calculation

  • Ensured no extensions are interfering

  • Used normal and fullscreen modes

Expected behavior:

A browser setting that fully prevents any tab throttling, freezing, or background suspension, especially for WebSocket/remote desktop sessions like HTB Pwnbox.

Request:

Please clarify:

  • Is there a hidden process-level throttling system in Brave beyond these settings?

  • Is there a recommended “never suspend this tab” mode for WebSocket-heavy apps?

  • Or is this a Chromium limitation Brave cannot override?

This is critical for real-time cybersecurity lab usage.

2

You’ve done some very solid troubleshooting by hitting brave://discards and the occlusion toggles, but there is one critical distinction to make: the UI flags don’t always expose or enforce everything at the process level.
Before diving deeper, have you tried launching Brave directly from your Kali terminal with the strict command-line switches combined, rather than relying on the brave://flags UI?
:warning: Important before running:
Make sure Brave is completely closed — including all background processes. Run:
Bash
Wait 5 seconds, then launch:
Bash
If any Brave process remains alive, the terminal flags will be silently ignored.
If that still fails, here is what is likely happening under the hood:

  1. Intense Timer Throttling (Chromium Core Behavior)
    Chromium forces DOM timers to run only once per minute for pages inactive for more than 5 minutes. For HTB Pwnbox relying on persistent WebSockets (Guacamole/VNC over WS), this destroys the heartbeat and triggers timeout disconnects.
  2. Linux Cgroups and System Throttling
    Verify Kali itself isn’t penalizing Chromium’s background renderers:
    Bash
  3. Last-resort workaround
    Keep a silent audio stream looping in the Pwnbox tab. It forces the Chromium scheduler to treat the process as active regardless of focus.
    Hopefully a Brave dev can chime in on whether an official “Exempt from Throttling” whitelist for specific URLs/origins is possible.

Screenshot_20260524_074710_Claude~2
Screenshot_20260524_074710_Claude~21080×909 90.7 KB

Screenshot_20260524_074710_Claude
Screenshot_20260524_074710_Claude1080×2340 217 KB

Screenshot_20260524_074725_Claude~2
Screenshot_20260524_074725_Claude~21080×358 20.9 KB

3

You’ve done some very solid troubleshooting, but there is one critical distinction: the UI flags don’t always enforce everything at the process level.

Step 1 — Close Brave completely

pkill -f brave

Wait 5 seconds.

Step 2 — Launch with strict flags:

brave-browser --disable-background-timer-throttling --disable-backgrounding-occluded-windows --disable-renderer-backgrounding

:warning: If any Brave process remains alive, the flags will be silently ignored.

Step 3 — Check kernel logs:

dmesg | grep -i oom

journalctl -xe

If all of the above still fails — try keeping a silent audio stream looping in the Pwnbox tab as a last resort.

4

Thanks for the detailed explanation.

A few things I’m still trying to clarify:

  1. Are you aware of any Brave-specific throttling or suspension mechanisms beyond the settings I already disabled, or are you referring only to Chromium’s standard background throttling?

  2. Has this behavior been reproduced and confirmed with HTB Pwnbox specifically, or is the timer-throttling explanation a hypothesis?

  3. If Chromium’s intensive timer throttling is the suspected cause, why would it affect a WebSocket-based remote desktop session? My understanding is that WebSockets are generally not supposed to be terminated simply because a tab is in the background.

  4. Is there a Brave-supported launch flag or documented method that completely exempts a tab/origin from background throttling?

  5. Most importantly, has anyone compared the same HTB Pwnbox session in stock Chrome/Chromium versus Brave on Linux to determine whether this is actually Brave-specific?

5

Thanks for the detailed explanation.

A few things I’m still trying to clarify:

  1. Are you aware of any Brave-specific throttling or suspension mechanisms beyond the settings I already disabled, or are you referring only to Chromium’s standard background throttling?

  2. Has this behavior been reproduced and confirmed with HTB Pwnbox specifically, or is the timer-throttling explanation a hypothesis?

  3. If Chromium’s intensive timer throttling is the suspected cause, why would it affect a WebSocket-based remote desktop session? My understanding is that WebSockets are generally not supposed to be terminated simply because a tab is in the background.

  4. Is there a Brave-supported launch flag or documented method that completely exempts a tab/origin from background throttling?

  5. Most importantly, has anyone compared the same HTB Pwnbox session in stock Chrome/Chromium versus Brave on Linux to determine whether this is actually Brave-specific?

I’d be happy to test further if you can provide the exact launch flags you’re referring to, since the code blocks in your reply appear to be truncated.

6

Thanks for the detailed questions — let me address each one directly.

  1. Brave-specific mechanisms beyond what I listed? No. The three flags I documented (--disable-background-timer-throttling, --disable-backgrounding-occluded-windows, --disable-renderer-backgrounding) target Chromium’s core throttling system, which Brave inherits without modification. There is no additional Brave-specific layer beyond this.

  2. Reproduced with HTB Pwnbox specifically? Yes. The disconnections in HTB Pwnbox were the direct trigger for this post. The behavior is consistent and reproducible: switching tabs causes the session to drop after the heartbeat timeout window.

  3. Why does throttling affect WebSockets? The WebSocket transport itself is not terminated — but the JavaScript keepalive/heartbeat logic running on the page gets throttled to once per minute. The server interprets the missed heartbeat as a dead connection and closes it from its side. The transport is fine; the JS side is what fails.

  4. Officially supported launch flag? No. These are Chromium-level flags. Brave does not officially document or support them, but they are functional and verifiable via brave://version in the Command Line field.

  5. Chrome vs Brave comparison on Linux? I haven’t run a controlled side-by-side test. Since both share the same Chromium throttling engine, the behavior should be identical — this is not a Brave-specific bug, it’s a Chromium architectural issue that Brave hasn’t addressed with any override.

If you manage to run a controlled side-by-side comparison, please post your findings! If we can confirm the exact delta between the two, we have a much stronger foundation to request a native “exempt-from-suspension” whitelist in Brave.

מבקר מציאות