Qwen Code GitHub Repository Filter: Allowlist, Blocklist and Missing Events

Qwen Code 0.27.0 adds a repository filter for its GitHub channel. You can process notifications from selected repositories or exclude noisy ones without changing who can instruct the agent. The important catch is that filtered notifications are not replayed when you change the filter later.

That makes this worth configuring deliberately. If an agent handles reviews across several repositories, a filter can stop an unrelated project from repeatedly waking it. It can also explain why a review request appears on GitHub but never reaches the agent.

What changed in Qwen Code 0.27.0

The November 7 release introduces a dedicated Repository Filter control in the Web Shell. Previously, repository restrictions were tied to the group access configuration, which was awkward when the goal was simply to ignore a few busy repositories.

The new control has three modes. Off applies no repository intake filter. Allowlist accepts notifications only from named repositories. Blocklist excludes the named repositories and lets the others continue to the remaining checks. Existing channels default to Off, so upgrading does not silently narrow their intake.

Passing the repository filter does not guarantee a response. Notification reasons, group access and sender rules still matter. Think of this setting as the first selection of incoming work, before the agent decides whether that work is allowed through the rest of the channel.

Set up an allowlist in the Web Shell

For an existing GitHub channel, open Settings, then Channels, then GitHub. Set Repository Filter to Allowlist. In Filtered Repositories, enter the repositories you want this channel to handle, using names such as acme/payments and acme/docs, then save.

The editor also accepts repository and pull-request URLs from the channel's GitHub host. It shortens those to owner/repo, lowercases them and removes duplicates. Check the saved names rather than assuming every pasted URL meant what you intended. The implementation rejects known non-repository areas such as organization pages, but its list of those areas is explicitly best-effort.

An active filter needs at least one valid repository. An empty Allowlist or Blocklist is rejected rather than interpreted as a special instruction. To disable filtering, choose Off. A previously stored list can remain saved while Off is selected without affecting intake.

Edit an existing channel in settings.json

The versioned GitHub channel guide documents two configuration fields: repoFilterMode and repoFilter. Add them inside the existing channel object under channels in ~/.qwen/settings.json.

For example, these fields limit intake to two repositories:

{
  "repoFilterMode": "allowlist",
  "repoFilter": ["acme/payments", "acme/docs"]
}

This is a fragment to merge into your channel, not a replacement for the complete settings file. Keep its existing authentication, working directory, operator and sender settings. When editing JSON directly, use canonical owner/repo strings rather than the URLs the Web Shell knows how to shorten.

To exclude a noisy archive instead, use:

{
  "repoFilterMode": "blocklist",
  "repoFilter": ["acme/archive"]
}

Repository matching is case-insensitive. For a channel with a small, fixed responsibility, I would use an allowlist. A blocklist is better suited to a channel intended to follow most of an account's repositories, but it also leaves newly visible repositories eligible unless another rule excludes them.

Why an allowed repository still gets no response

Suppose the repository filter allows acme/payments and acme/docs, while the group access policy permits only acme/payments. Notifications from acme/docs still fail the later access check. The effective repository set is the intersection of both restrictions, as the filter design documents.

Start troubleshooting in the Channel event timeline. A repo_filter skip means the intake filter excluded that notification. If that is absent, inspect the notification reason and group or sender policy rather than widening every setting at once.

There are two other easy traps. The authenticated GitHub account cannot trigger its own channel through its own activity, so testing with the bot account can produce a false failure. Also, a reasonFilter containing only mention is not equivalent to requiring a mention: GitHub can deliver later mentions under other thread-level reasons. Preserve the appropriate mention and sender controls instead of treating the reason filter as a shortcut.

Why changing the filter does not restore missed work

Filtered notifications advance through the polling window and are marked read when accepted work in that window completes. Removing a repository from a blocklist does not make those earlier notifications run again. Verify a changed configuration with fresh, authorized activity from an account permitted to operate the channel.

There is a separate exception for explicitly watched pull requests. Ordinary notifications about a PR bound to a live session still pass through the repository filter. Its PR state-watch events, configured through prWatchEvents, bypass that intake path. Blocking a repository is therefore not a universal stop switch for every existing PR watcher.

A repository filter should make an agent's responsibility easier to explain. Keep that responsibility narrow enough that you can name the repositories it should follow, then test both an included and an excluded case before relying on the silence.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product changes and engineering decisions into useful content developers can understand and share.

Book a 30-minute call.