---
title: My visitor can't see the agent's replies. What's wrong?
question: visitor cant see replies
area: support
audience: beginner
surface: both
keywords: [no replies, cant see replies, replies not showing, blank after refresh, messages not appearing, allowed domains, origin not allowed, domain, cors, widget not updating, one way, visitor sends but no answer]
related: [how-do-i-add-the-chat-widget-to-my-website, what-do-my-visitors-see-in-the-chat, how-do-i-reply-to-and-manage-support-conversations, how-does-support-answer-when-my-desktop-is-closed]
updated: 2026-07-21
---

# My visitor can't see the agent's replies. What's wrong?

Almost always, the site's domain is not on the instance's allowed-domains list. When that happens, the widget can send a message but is blocked from reading anything back, so the visitor sees their own message and never the replies, and the conversation looks blank if they refresh. Add the site's domain to the instance's **domains** field and it starts working. Everything else on this page is a rarer cause.

## The usual cause: the domain is not allowed

Each instance has an allowed-domains list. It protects your key, but it also governs whether the widget can read replies. If a visitor's site is not on the list, sending works but reading is blocked, which looks exactly like "the agent never replies".

To fix it:

1. In codus, open the **chats** tab and click **▶ instances**.
2. Expand the instance and find the **domains** field.
3. Add the domain your site is served from, for example `app.example.com`. You can use a wildcard like `*.example.com` to cover subdomains. Separate several with commas.
4. Click away from the field to save.

Two useful details:

- An **empty** domains list means any domain is allowed. That is handy while testing, but worth locking down before launch.
- `localhost` is always allowed, so testing on your own machine works even with a domains list set. That is why a chat can work in your own testing but fail once it is live on a real domain that you forgot to add.

## Check someone is actually answering

If the domain is definitely allowed and replies still are not coming:

- **Is codus open and signed in?** While your desktop is online, it answers and lets you reply. If it is closed, answers come from the cloud instead, which needs a support brief. See [Who answers my visitors when codus is closed?](how-does-support-answer-when-my-desktop-is-closed.md).
- **Is there a support brief?** With codus closed and no fresh brief, the cloud parks the conversation and the visitor sees "the team has been notified" rather than a real answer. Generate one from the instance card.
- **Is the conversation waiting?** A conversation shown as **waiting** in your **chats** tab is held for a person. Open it and reply to pick it up.

## A slow reply is not the same as no reply

Replies normally appear within a second or two thanks to a live update channel. Some websites have strict security rules that block that channel. When that happens the widget quietly falls back to checking for new messages every couple of seconds instead, so replies still arrive, a touch slower. A blocked live channel is not a cause of replies never appearing; that is the domains list.

## How do I know it worked?

Open your live site (not localhost), send a test message through the bubble, and reply to it from the **chats** tab in codus. The reply should appear in the widget within a couple of seconds, and still be there if you refresh the page.

## Common problems

**It works on localhost but not on the live site.** The live domain is not on the allowed list. `localhost` is always allowed, which masks the problem during testing. Add the real domain to the instance's **domains** field.

**The visitor sees their own messages but nothing back, and a refresh shows an empty chat.** This is the classic sign of the domain being blocked from reading. Add the domain as above.

**Replies appear in codus but not in the widget.** Same cause: the widget on that domain cannot read back. Fix the domains list.