Cannot edit current search with new search bar

[w-biggs]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Code Search and Navigation

Body

Today, the search bar has changed significantly so that it's (sometimes) much smaller at the top of the page and a modal opens when you click it. With these changes, there is no way to edit the current search terms. If I have a long search and want to add something to it to refine the search, I now have to either type the entire search back in or manually edit the current URL instead. I also cannot see what the current search was without looking at the URL or clicking the search bar and looking at the most recent item.

This is what I see now after searching for "repo:angular/angular this is a long search query"

And if I want to edit that search, I have to re-type the entire thing -- there's no way to just edit my current search. This is what I see when I open the modal:

Clicking that top recent item just triggers a search with that query -- it doesn't populate the text box or anything. There's literally no way to refine a search without typing it all in all over again anymore.

This seems like a really poor UX decision that goes against how search bars work on every other website if it's on purpose, so I'm assuming it's a bug. I think this began today, or within the last week at least. I don't see anything related in the changelog.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[TranscranialAvenue]

Confirming I'm experiencing the exact same issue. The top search bar no longer displays
my current search query—it just shows the placeholder "type / to search" even when
viewing active search results.

Reproduction:

• Perform any search on GitHub
• Navigate to the results page
• The search field at the top still shows "type / to search" instead of the query

Environment:

• Reproducible across multiple browsers (Chrome + Vivaldi)
• Occurs whether logged in or not
• Affects all search result pages (code, repos, issues, etc.)

Workaround:
For now, I can edit the search query directly in the browser URL bar (modifying the
q= parameter in the URL) to refine searches without relying on the search field UI.

This is a clear regression—the search bar used to display/retain the active query for
quick editing. The functionality works when you click the field and type, but the visual
feedback of the current query is missing.

@github/support — flagging for triage. This appears to be a widespread UX regression
affecting multiple users.

[ntessman-capsule]

This is a wild product decision. Even if the search text did populate properly, hiding the input behind a modal dialogue activated by a click or key stroke doesn't improve or streamline the UX in any way. It's worse than useless.

ETA: There's already the command palette feature preview that is a modal hidden behind a key stroke that supports search. What exactly is the purpose of making a second, worse version of the same thing that was unceremoniously tested on end users without ever being behind a feature flag?

[Tanaka62700]

Hello bro I have many mistakes when I use the github
can you help me?

[memchr]

The filter autocomplete and highlighting features are gone too.

[llakala]

This is abhorrent product design.

[AzureFlow]

As somebody who uses the search feature a lot, this is one of the most infuriating updates lately.

[rummik]

The new design breaks common usability guidelines by turning the search box into a button, and raises major accessibility concerns. It wasn't even done as an experiment to collect feedback on, and can't be disabled because of that.

[miroslavapeneva629-cyber]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Code Search and Navigation

Body

Today, the search bar has changed significantly so that it's (sometimes) much smaller at the top of the page and a modal opens when you click it. With these changes, there is no way to edit the current search terms. If I have a long search and want to add something to it to refine the search, I now have to either type the entire search back in or manually edit the current URL instead. I also cannot see what the current search was without looking at the URL or clicking the search bar and looking at the most recent item.

This is what I see now after searching for "repo:angular/angular this is a long search query"

And if I want to edit that search, I have to re-type the entire thing -- there's no way to just edit my current search. This is what I see when I open the modal:

Clicking that top recent item just triggers a search with that query -- it doesn't populate the text box or anything. There's literally no way to refine a search without typing it all in all over again anymore.

This seems like a really poor UX decision that goes against how search bars work on every other website if it's on purpose, so I'm assuming it's a bug. I think this began today, or within the last week at least. I don't see anything related in the changelog.

[miroslavapeneva629-cyber]

As somebody who uses the search feature a lot, this is one of the most infuriating updates lately.

[DrVrej]

Can confirm I have the same issues, I would like to also mention that another bug was introduced as well. After a search query, there is now a chance where you can no longer click the GitHub icon to go back home.

[TranscranialAvenue]

Edit of Copilot bug report for user @TranscranialAvenue
### We all want the query field to persist/remain-populated for ease/speed/convenience of edit

**

I'd welcome anyone to give me/us a different point of view. . .

**

Confirming I'm experiencing the exact same issue. The top search bar no longer displays
my current search query—it just shows the placeholder "type / to search" even when
viewing active search results.

Reproduction:

• Perform any search on GitHub
• Navigate to the results page
• The search field at the top still shows "type / to search" instead of the query

Environment:

• Reproducible across multiple browsers (Chrome + Vivaldi)
• Occurs whether logged in or not
• Affects all search result pages (code, repos, issues, etc.)

Workaround:
For now, I can edit the search query directly in the browser URL bar (modifying the
q= parameter in the URL) to refine searches without relying on the search field UI.

@github/support — flagging for triage. This appears to be a widespread UX regression
affecting multiple users.

[2meito]

EBVKA on ycombinator created a userscript which works around this issue by making a custom search bar with a tag and filter system:

For those not wanting to use a userscript, clicking one of the advanced search sidebar options also shows a "query-builder-container":

Makes me wonder why GitHub even made the new search modal at all since it seems to be just a worse version of this.

[Zhytariuk]

Thanks, bro

[nickchomey]

This is one of the worst UX regressions I've come across in a long time. It makes search utterly unusable. I FREQUENTLY make a search, then click in it again to change the search term. Now when I do that, it just does a global search across all of github because it no longer has repo:{org/repo} {previous search term} in the box.

How this ever passed the brainstorming phase, let alone code review and QA (if those even exist anymore), is bewildering

[grande1900]

My guess as to why this was done as just to shill copilot by placing the button smack dab in the middle of your screen without any care put into what the consequences would be

[benpriestman]

I'd like to add my name to list of the people dismayed by this change. Searching across repos for arbitrary text or regex and then refining the terms is something I do a lot. If this is a problem for github and I need to switch to a pay-per-use API that I need to write my own client for, I'd prefer to have been told, rather than have the capability disappear without warning.

[gameroman]

The new search is horrible and completely broken

[randall-krauskopf]

Hello all, as many of you noticed, a regression in our search functionality was accidentally introduced on Friday, June 26. We rolled back those changes on June 29, 2026 at 15:01:11 UTC, and this issue should no longer be occurring for users.

We sincerely apologize for the disruption to your workflows.

[gameroman]

Thakn you!