CLAWPOD ENGINEERING
When Browser Push Is Missing: Separate Account Preferences from Device Permission
Distinguish in-app notifications from browser push in ClawPod Cloud, investigate missing delivery, and leave a useful record for your team.
Notifications visible on your office computer may be missing on your home laptop. This guide helps people using ClawPod Cloud across devices distinguish notification problems and leave a useful record for their team. You need access to the Portal through your own account, and the person using each device decides whether to change its settings. In-app notifications are checked inside the product; browser push is a separate delivery method that uses the browser’s notification permission.
Record “enabled” separately from “delivery confirmed”
- Distinguish in-app preferences from browser push preferences. Enabling one does not establish that the other is ready.
- Push depends on permission in the current browser and site. Check each device you actually plan to use.
- A missing notification does not establish that the original request or task is absent. Check important information in the linked original record.
The paths below describe the ClawPod Cloud Portal, as documented in the official Guide. They are not settings paths in the Agent Control UI, which concerns the Agent execution environment. This is not a walkthrough verified against a current signed-in screen: ask your administrator if your deployment differs. It does not guarantee delivery or determine support for every browser.
Start with your own delivery preferences
The Guide gives two entry points: your account name at the bottom left, then Settings → Notifications, or the top Notifications → View all notifications. Personal settings are separate from the top administration menu. These controls change your own account’s delivery preferences, not another user’s settings or an Agent’s execution policy.
The documented sequence is to enable or disable in-app notifications, then enable push in a supported browser and approve the browser permission request. Do not expect permission to appear automatically. When you want push, turn it on yourself and read the browser’s request before deciding.
General web-notification conditions are useful context, but keep their scope separate. MDN explains that permission requests should respond to a user gesture such as a button click, and that Chrome and Firefox require a secure context (HTTPS). These are browser API conditions, not a complete ClawPod Cloud support list or evidence of successful delivery. Asking an Agent to “turn notifications on” should not be treated as a substitute for the browser user’s consent.
Check again when the browser or device changes
The Guide says push depends on the browser and current origin. For this check, inspect permission for the Portal site you are using. Another browser or device needs separate permission. Permission on your office computer is not evidence of delivery on your home laptop.
According to the Guide, the push toggle cannot be enabled if browser permission was denied or the environment is unsupported. Check operating-system notification blocking as well as the browser’s site permission when something goes wrong. If permission is denied, inspect that browser’s site permission before repeating the request. Whether to change it is a decision for the device user within organizational policy.
| Symptom | Check first | What this check alone does not establish |
|---|---|---|
| Missing on one device | That device’s browser and site permission, plus OS notification blocking | Whether the original event occurred or push was actually sent |
| Push toggle cannot be enabled | Denied browser permission and environment support | Whether another browser has the same issue |
| A colleague sees an extra type | Each person’s role and the types actually displayed | Whether every user has the same types |
| Settings screen cannot be found | Role, current organization, top-level mode, and allowed menus | Permission to guess URLs or broaden access |
This table gives an investigation order, not a diagnosis that every missing notification is a browser-permission problem. Even when permission is granted, delivery needs a separate check.
Example: hand over the home laptop’s delivery status
This is an illustrative example. Devices and observations are sample material, not an actual test or a report the product generates automatically. A Room is a space where users and Agents converse. Here, the user asks an Agent to organize observations the user has already made.
The reader’s request
I do not see notifications on my home laptop. Here is what I checked: I saw a message notification on my office computer today, and the same Portal site’s notification permission is blocked on my home laptop. At home, I checked the message in the original Room. Put these observations in a table and tell me what to check next. Do not change settings or permissions or send a test notification. Do not mark unverified delivery as successful.
Filled result sample — illustrative example
| Target | Observation supplied by the user | Assessment and next action |
|---|---|---|
| Office computer | A message notification was seen today | Record that observation only. It does not establish the home laptop’s status |
| Home laptop | Notification permission for the same Portal site is blocked | The user checks browser site permission and OS blocking, then decides whether to change anything |
| Original Room | The message content was checked directly | That message has been checked; push delivery to the home laptop is still unverified |
| Execution scope | No settings changed and no test sent | Leave a next check rather than closing the issue as delivery confirmed |
Split success verification into two parts. First, check that the table matches the supplied observations and that the Agent has not invented settings changes or successful delivery. To establish actual push readiness, after a user-approved change, observe the notification on that device and the original Room message separately in an authorized messaging situation. This is a proposed team verification procedure, not a claim that the product has a dedicated test-send button. Record the time, device, browser, site, and actual outcome.
Attach failure recovery to the same record. If permission is granted but nothing appears, record “permission granted; delivery unverified,” then check OS blocking, the displayed notification types, and the original message. If the issue remains, send those observations to your administrator. Do not repeatedly send tests or broaden permissions. Until resolved, hand over direct checks of the original Room to an agreed owner. Do not generalize one result to delivery of every notification type.
Pair role-dependent types with a fallback check
The Guide says administrator roles may see additional types such as messages, Agent errors and lifecycle, security, system, Skill, and usage. Tenant administrators may see member-related types, while ordinary members may see only message notifications. You can enable or disable only the types displayed to you, so do not tell a colleague to reproduce your screen exactly.
The Guide warns you to establish an alternative monitoring path before disabling important Agent-error or security notifications. Agree who will check which original record and when. Do not assume a particular dashboard replaces every notification with identical information. Disabling these preferences does not delete original events or execution records for Agents, tasks, or webhooks.
If a menu is missing, check your role, current organization, top-level mode, and allowed menus, then ask the tenant administrator. Do not guess URLs or broaden permissions because an entry is absent.
Read status, notification deletion, and checking the source are different actions
The Guide describes using type and severity filters in the full notification list, checking the linked target, and then choosing individual or bulk mark-as-read actions. For important operational notifications, check the original Room, event, or task record before marking them read.
The full list has no delete button. The panel opened by the top notification button has a per-item delete-notification action. Marking an item read does not change the original data in its linked Room, task, Agent, or webhook. Do not use “marked read,” “deleted the notification,” and “checked the original message” interchangeably in a handover.
Delivery with all tabs closed or the browser shut down, latency, and retry guarantees have not been verified here. Do not assume push is the only monitoring path needed for important work. Start today with one device you will actually use, and record delivery preferences, browser permission, and observed delivery as separate fields.
