Wavebox not working: what to check, in order

Notifications stop appearing. Tab switching gets sticky. Google asks for a sign-in again, two weeks after the last one. These feel like the same category of problem, which is why the usual response is to start changing settings until something shifts. That approach costs an afternoon and usually ends with a configuration nobody can explain.

There is a better order. Every symptom in this product sits in one of three layers, and each layer has its own checklist published by the vendor. Identifying the layer first turns a vague problem into a short sequence of tests.

Sort the symptom into a layer before touching anything

The app layer covers rendering problems, sluggishness, features that do not respond, and one specific site behaving badly. Something inside the browser or inside an extension is responsible. A reload or an update changes the outcome, which is the signature of this layer.

The account layer covers repeated sign-out, authentication prompts on a schedule, and sessions that will not persist. The cause frequently sits on the service side rather than in the browser, and no amount of local configuration will change it.

The permission layer covers notifications that never arrive, microphone and camera access, and downloads that fail at the last step. macOS, or a security product running alongside it, is blocking something. Nothing inside the browser's own settings will show the cause.

Symptom	Layer	First action
Page renders wrong	App	Hard reload with Shift held
General slowdown	App	Update, then sort Navigator by memory
Feature unresponsive	App	Disable extensions, then fully restart
Signed out every two weeks	Account	Check whether the account is Workspace
No notifications on macOS	Permission	Send a test notification, then check System Settings
Download blocked	Permission	Check the security software, not the browser

Sorting first also prevents the most expensive mistake in troubleshooting, which is making three changes at once and losing the ability to tell which one mattered.

The app layer checklist, in the published order

The general checklist runs from the lightest action to the heaviest, and skipping steps tends to cost more time than it saves.

Start with a reload using the icon beside the address bar. If nothing changes, hold Shift and click it again for a hard reload, which fetches without using the cache and resolves most display faults on its own.

Next, quit and relaunch. If the machine has been running for days without a restart, restart it too. This is unsatisfying advice and it still resolves a meaningful share of reports.

Third, confirm the version is current. Settings, then the General tab, then About, then the button to check for updates. A bug that has already been fixed upstream will keep reproducing on an old build indefinitely. Restart the machine after updating, then try to reproduce.

Fourth, try the same thing in another Chromium browser. Because this browser shares that foundation, some faults are inherited from upstream rather than introduced locally. If Chrome or Edge shows the identical behaviour, the problem is not specific to this product, and that single finding is one of the most useful things a support ticket can contain.

Narrow it down with extensions and a blank profile

When the four steps above change nothing, the next job is deciding whether the cause lives in an extension or in the configuration.

For extensions, open the puzzle piece icon in the toolbar and choose the option to manage extensions, then switch each one off. With a long list, turning on developer mode reveals a control that disables all of them at once. The critical detail, stated explicitly in the vendor documentation, is that disabling is not enough on its own: the application has to be fully restarted before the change takes effect. Plenty of people conclude that extensions were innocent because they skipped the restart.

If the symptom disappears, re-enable extensions one at a time until it returns. Once the culprit is identified, remove it, restart, and reinstall it from the store so that any pending update comes along. Reporting the extension name to support is worth doing even after a local fix.

For configuration, create a fresh profile. The profile icon at the top right has an option to add one; give it a name, and a blank environment opens with no apps and no extensions. Reproduce the same action there. If it behaves correctly, the cause is something in the original profile. If it misbehaves identically, the cause is in the browser itself or in the site being visited.

This pincer approach looks slow and is in fact the fastest route, because a support conversation that starts without it will simply request these two tests before anything else happens.

When everything feels slow

Performance has a separate published sequence, and it starts in the same place: update, then restart.

After that, open the Navigator list and sort it by memory usage, then sort it again by CPU usage. Anything sitting far above the rest is the candidate. A moon icon puts a tab to sleep, and a close button removes it, with closing described as the better option for performance.

Then return to extensions. Heavy processing extensions, with AI tools called out specifically, are named as a common cause of slowdown. The disable-everything-then-restart procedure applies here as well.

If the cause is still unclear, the built-in task manager gives a per process breakdown. It opens from the menu at the top right, under more tools. Processes are labelled by purpose, which distinguishes a heavy tab from a heavy extension from a heavy utility process such as networking or audio. To connect this view to Activity Monitor on macOS, match the process ID shown in the browser against the PID column. Seeing several entries in Activity Monitor is normal rather than a fault, because each tab runs in its own process, with separate helper processes for rendering, GPU work, and networking. Worth noting: CPU usage rises while the task manager itself is open, so the numbers read slightly high.

Notifications on macOS are a permissions question

A silent notification is almost always a permission that was never granted, and there are two places to look.

Inside the application, open the settings cog at the bottom left, choose notifications in the sidebar, and use the test notification button. A correctly configured install produces two notifications. One notification, or none, means the check continues.

In macOS, open the system settings for notifications. Two entries appear, one for the browser itself and one for its alerts helper. The documented configuration is notifications allowed for both, with the main entry set to banners and the helper set to alerts. A half-granted state is exactly what produces one test notification instead of two. After correcting it, press the test button again rather than assuming.

Getting permission right is a separate question from deciding which app should be allowed to interrupt at all. Structuring notifications so that each app carries its own identity and its own rules is covered under Features.

The two week sign-out is a policy, not a fault

One frequently reported symptom should not be treated as a defect, because its cause is outside the browser entirely.

By default, Google Workspace (formerly G Suite) accounts are set to re-authenticate every two weeks. Source: hub.wavebox.io

That is a Google session policy applied across browsers, not something a browser can override. Switching products will reproduce the same two week rhythm.

There are two responses. A Workspace administrator can change the web session length in the admin console, with the caveat that the change applies to every user and every session rather than to one application. Anyone who is not an administrator is better off making the sign-in fast instead, using a password manager so that the fortnightly prompt costs seconds.

Personal addresses ending in gmail.com are explicitly outside this policy. If one of those keeps dropping, the more likely explanation is a changing location or IP address, which makes a VPN the first thing to test rather than the last.

Three faults that look general but are not

Some symptoms appear to be broad failures and turn out to have one narrow cause each. Recognising them saves the whole checklist above.

Video or audio that will not play, on a site where playback normally works, points at the protected media plugin rather than at the browser. That component downloads in the background after installation, and if the download did not complete, playback fails while everything else behaves normally. The published guidance treats this as its own case with its own fix, separate from general playback trouble.

A download that fails at the final moment with a message about a failed virus scan is a Chromium-level behaviour, not a product-specific one. The same message appears in Chrome, Brave and Edge under the same conditions, which is a strong hint that changing browsers will not help. The cause usually sits in the security software or in the system component the browser asks to perform the scan.

A warning from antivirus software about a newly downloaded version is the third case. New builds are unfamiliar to signature-based products, and a fresh release can be flagged simply for being fresh. The documented response is to verify the source of the build rather than to disable protection, and to report the detection so it can be addressed at the vendor level.

What these three share is that the browser is the place the symptom appears rather than the place the cause lives. Running the full app-layer checklist against them wastes an afternoon, which is the argument for sorting the symptom into a layer before starting.

What to collect before opening a ticket

Once the layer is identified and the local tests are done, the quality of the report determines how many rounds the conversation takes.

Three items are requested by name. A specific description of the behaviour, written in terms of actions rather than impressions, so slow tab switching rather than feels sluggish. A screenshot of the built-in task manager with the window widened so every column is visible. And a diagnostics bundle, generated from settings, then advanced, then the generate diagnostics button, which takes a few minutes to build and is then sent with its own send button.

One step gets forgotten constantly: telling support that the bundle has been sent. Generating and sending it does not attach it to a ticket by itself.

What to change first

Decide the layer before changing a setting, and write down where the symptom stopped reproducing: which layer, which extension, whether a blank profile showed it. That single note turns the next occurrence into a two minute check instead of another afternoon. If the pattern turns out to be the account or permission layer repeating, the fix is structural rather than a setting, and the approach of giving each app its own window and its own permissions is described in SpaceDeck.