I think this fear is overblown. What Vouch protects against is ultimately up to the downstream but generally its simply gated access to participate at all. It doesn't give you the right to push code or anything; normal review processes exist after. It's just gating the privilege to even request a code review.
Vouch is forge-agnostic. See the 2nd paragraph in the README:
> The implementation is generic and can be used by any project on any code forge, but we provide GitHub integration out of the box via GitHub actions and the CLI.
And then see the trust format which allows for a platform tag. There isn't even a default-GitHub approach, just the GitHub actions default to GitHub via `--default-platform` flag (which makes sense cause they're being invoked ON GITHUB).
So I can choose from github, gitlab or maybe codeberg? What about self-hosters, with project-specific forges? What about the fact that I have an account on multiple forges, that are all me?
This seems to be overly biased toward centralized services, which means it's just serving to further re-enforce Microsoft's dominance.
It's a text string, platform can be anything you want, then use the vouch CLI (or parse it yourself) to do whatever you want. We don't do identity mapping, because cross-forge projects are rare and maintaining that would centralize the system and its not what we're trying to do. The whole thing is explicitly decentralized with tiny, community specific networks that you build up.
I consider myself a craftsman as well. AI gives me the ability to focus on the parts I both enjoy working on and that demand the most craftsmanship. A lot of what I use AI for and show in the blog isn’t coding at all, but a way to allow me to spend more time coding.
This reads like you maybe didn’t read the blog post, so I’ll mention there many examples there.
I like using AI for visualizations because it is one-time use throwaway code, so the quality doesn't matter at all (above not being TOTALLY stupid), it doesn't need to be maintained. I review the end result carefully for correctness because it's on a topic I'm an expert of.
I produce non-reusable diagrams namespaced by blog post (so they're never used by any other post). I just sanity check that the implementation isn't like... mining bitcoin or leaking secrets (my personal site has no secrets to build) or something. After that, I don't care at all about that quality.
The information is conveys is the critical part, and diagrams like this make it so much more consumable for people.
That's really cool. I was looking at them and thinking "I could probably make these with vanilla html/css but it'd be pretty tedious." Perfect use case for AI. I need to work on developing a reflex for it.
I've also started doing this, and it's surprisingly enjoyable to both do and even to read. The end result is often more readable to me than using a 3rd-party JS visualization library, because I only need to know standard HTML/CSS concepts to understand what's going on. And a side benefit is smaller pages with less bitrot due to being able to skip the dependencies.
> Probably not a huge deal, but it does seem the fix will needlessly delete and recreate non-standard pages in the case where the new page needs to be non-standard, and the oldest one (that needs to be pruned) already is non-standard and could be reused.
This is addressed in the blog post.
It is how the PageList has always worked, and also how it worked before with the bug, because during capacity adjustment we would see the wrong size. This shouldn't change any perceived performance.
And as I note in the blog post, there are alternative approaches such as the one you suggested, but we don't have enough empirical data to support changing our viewpoint on that whereas our current viewpoint (standard sizes are common) is well supported by known benchmarks. I'm open to changing my mind here, but I didn't want to change worldviews AND fix the leak in the same go.
Of all the things to be impressed by you about, your patience is commendable. I'd be losing my shit if someone couldn't be bothered to read what I wrote and just spout off about something I'd addressed in my writing, but I suppose that's why your bank account has two commas and a bunch more. Thank you for everything. Can we go flying sometime?
> I'd be losing my shit if someone couldn't be bothered to read what I wrote and just spout off about something I'd addressed in my writing
In my experience that’s a universal feature of comment sections everywhere, and HN is not an exception. This is very common in HN comments which is why it’s important to always read the article, not just the comments.
What contrast? I stand by what I said there. I just re-read every point and I would say the same thing today and I don't think my blog post contradicts any of that?
A user came along and provided a reliable reproduction for me (last night) that allowed me to find and fix the issue. Simultaneously they found the same thing and produced a similar fix, which also helped validate both our approaches. So, we were able to move forward. I said in the linked comment that I believed the leak existed, just couldn't find it.
It also was fairly limited in impact. As far as Ghostty bugs go, the number of upvotes the bug report had (9) is very small. The "largest" in the title is with regards to the size of the leak in bytes, not the size of the leak in terms of reach.
As extra data to support this, this bug has existed for at least 3 years (since the introduction of this data structure in Ghostty during the private beta). The first time I even heard about it in a way where I can confidently say it was this was maybe 3 or 4 months ago. It was extremely rare. I think the recent rise in popularity of Claude Code in particular was bringing this to the surface more often, but never to the point it rose to a massively reported issue.
> I think the recent rise in popularity of Claude Code in particular was bringing this to the surface more often, but never to the point it rose to a massively reported issue.
I'm not sure you can make that argument in good faith; especially as everything is forced to be a discussion and dupes are aggressively closed - so how do you quantify "massively reported issue"?
Discussion upvotes, discussion activity, and Discord reorts. I read every discussion and have been doing this project specifically for a few years now. There is a stark difference between a widespread and common bug and something like this.
Like I said, this bug has existed for 3 years at this point and Ghostty is likely used by hundreds of thousands if not a million+ people daily (we don't have any analytics at all but have some side signals based on terminal reports from 3rd party CLIs). Trust me when I say that when there is a widespread issue, we hear it MUCH more loudly. :)
Dupes are not deleted, you can just search for them and see that there are not that many of those, and that's with this not being the only unsolved memory leak (https://github.com/ghostty-org/ghostty/discussions/9314 is a different one).
To be clear, I think discussions on the whole as a product are pretty bad. I'm not happy having to use them, but given my experience trying different approaches across multiple "popular" projects on GH, this approach has so far been the least bad. Although I'm still sad about it.
> Yeah but a good issue tracker should be able to help you filter that stuff out.
Agreed. This highlights GitHub's issue management system being inadequate.
Because I don't want my default view to be "triage." If GitHub allowed default issue views (and reflected that in the issue count in the tabs as well), then maybe. But currently, it doesn't work. I've tried it at large project scale across many (multiple projects with more than 20K stars and millions of downloads).
Compared to that, this system has been a huge success. It has its own problems, but it's directionally better.
How does different count affect search? You can use a bookmark to change the view, and if using bookmarks is too much, ok, but that's not a bold universal reason.
(also, what is "huge success" in methods of organizing issues?)
bookmark: (and if your browser supports shortcuts, it can be as easy to open as remembering to type a single char)
Here is an abridged set of reasons, just because it quickly turns into a very big thing:
1. The barrier to mislabel is too low. There is no confirmation to remove labels. There is no email notification on label change. We've had "accepted" issues accidentally lose their accepted label and enter the quagmire of thousands of unconfirmed issues. Its lost. In this new approach, every issue is critical and you can't do this. You can accidentally _close_ it, but that sends an email notification. This sounds dumb, but it happens, usually due to keyboard shortcuts.
2. The psychological impact of the "open issue count" has real consequences despite being meaningless on its own. People will see a project with 1K+ issues and think "oh this is a buggy hell hole" when 950 of those issues are untriaged, unaccepted, 3rd party issues, etc.
My practical experience with #2 was Terraform ~5 years ago (when I last worked on it, can't speak to the current state). We had something like 1,800 open issues and someone on Twitter decided to farm engagement and dunk on it and use that as an example of how broken it is. It forced me to call for a feature freeze and full on-hands triage. We ultimately discovered there were ~5 crashing bugs, ~50 or so core bugs, ~100 bugs in providers we control, and the rest were 3rd party provider bugs (which we accepted in our issue tracker at the time) or unaccepted/undesigned features or unconfirmed bugs (no reproduction).
With the new approach, these are far enough away that it gets rid of this issue completely.
3. The back-and-forth process of confirming a bug or designing and accepting a feature produces a lot of noise that is difficult to hide within an issue. You can definitely update the original post but then there might be 100 comments below that you have to individually hide or write tooling to hide, because ongoing status update discussions may still be valuable.
This is also particularly relevant in today's era of AI where well written GH issues and curated comments produce excellent context for an agent to plan and execute. But, if you don't like AI you can ignore that and the point is still valid... for people!
By separating out the design + accept into two separate posts, it _forces_ you to rewrite the core post and shifts the discussion from design to progress. I've found it much cleaner and I'm very happy about this.
4. Flat threads don't work well for issue discussion. You even see this in traditional OSS that uses mailing lists (see LKML): they form a tree of responses! Issues are flat. Its annoying. Discussions are threaded! And that is very helpful to chase down separate chains of thought, or reproductions, or possibly unrelated issues or topics.
Once an issue is accepted, the flat threads work _fine_. I'd still prefer a tree, but it's a much smaller issue. :)
-----------
Okay I'm going to stop there. I have more, many more, but I hope this gives you enough for you to empathize a bit that there are some practical issues, and this is something I've both thought of critically for and tried for over a decade.
There's a handful of people in this thread who are throwing around words like "just" or "trivially" or just implying how obvious a simple solution looks without perhaps accepting that I've been triaging and working on GH issues in large open projects full-time non-stop for the last 15 years. I've tried it, I promise!
This is completely a failure of GitHub's product suite and as I noted in another comment I'm not _happy_ I have to do this. I don't think discussions are _good_. They're just the _least bad_ right now, unfortunately.
>2. The psychological impact of the "open issue count" has real consequences despite being meaningless on its own. People will see a project with 1K+ issues and think "oh this is a buggy hell hole" when 950 of those issues are untriaged, unaccepted, 3rd party issues, etc.
Fully agree with this; as a beginner in the space I get nervous when I see a project having a thousand open issues since 2018.
Point #2 is very true for me. I get concerned when I look at a project and see thousands of issues. For safety and to not waste my time, if I see that and the project is an unknown to me, I just have to believe that it indicates the project is not being maintained properly.
I definitely think splitting discussion and issues is a good idea for that reason alone.
I usually try to scan the issues and look at a few, to get a vibe of what the makeup of that number is. It can be really attractive to try to just compare project metrics like that, though.
Not to mention you can restrict who can file issues with permissions. So you have a forcing function, whereas hoping tags are correctly applied is a never ending battle.
Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended!
I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here:
1. The report at hand seems to affect a very limited number of users (given the lack of reports and information about them). There are lots of X meme posts about Ghostty in the macOS "Force Close" window using a massive amount of RAM but that isn't directly useful because that window also reports all the RAM _child processes_ are using (e.g. if you run a command in your shell that consumes 100 GB of RAM, macOS reports it as Ghostty using 100 GB of RAM). And the window by itself also doesn't tell us what you were doing in Ghostty. It farms good engagement, though.
2. We've run Ghostty on Linux under Valgrind in a variety of configurations (the full GUI), we run all of Ghostty's unit tests under Valgrind in CI for every commit, and we've run Ghostty on macOS with the Xcode Instruments leak checker in a variety of configurations and we haven't yet been able to find any leaks. Both of these run fully clean. So, the "easy" tools can't find it.
3. Following point 1 and 2, no maintainer familiar with the codebase has ever seen leaky behavior. Some of us run a build of Ghostty, working full time in a terminal, for weeks, and memory is stable.
4. Our Discord has ~30K users, and within it, we only have one active user who periodically gets a large memory issue. They haven't been able to narrow this down to any specific reproduction and they aren't familiar enough with the codebase to debug it themselves, unfortunately. They're trying!
To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users. That's why the discussion is open and we're soliciting input. I even spent about an hour today on the latest feedback (posted earlier today) trying to use that information to narrow it down. No dice, yet.
If anyone has more info, we'd love to find this. :)
This illustrates the difficulty of maintaining a separation between bugs and discussions:
> To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users
In this case it seems you believe a bug exists, but it isn't sufficiently well-understood and actionable to graduate to the bug tracker.
But the threshold of well-understood and actionable is fuzzy and subjective. Most bugs, in my experience, start with some amount of investigative work, and are actionable in the sense that some concrete steps would further the investigation, but full understanding is not achieved until very late in the game, around the time I am prototyping a fix.
Similarly the line between bug and feature request is often unclear. If the product breaks in specific configuration X, is it a bug, or a request to add support for configuration X?
I find it easier to have a single place for issue discussion at all stages of understanding or actionability, so that we don't have to worry about distinctions like this that feel a bit arbitrary.
Is the distinction arbitrary? It sounded like issues are used for clear, completable jobs for the maintainers. A mysterious bug is not that. The other work you describe is clearly happening, so I'm not seeing a problem with this approach other than its novelty for users. But to me it looks both clearer than the usual "issue soup" on a popular open source project and more effective at using maintainer time, so next time I open-source something I'd be inclined to try it.
Some people see "bug tracker" and think "a vetted report of a problem that needs fixing", others see "bug tracker" and think "a task/todo list of stuff ready for an engineer to work on"
Both are valid, and it makes sense to be clear about what the teams view is
Agreed. Honestly, I think of those as two very different needs that should have very different systems. To me a bug tracker is about collecting user reports of problems and finding commonalities. But most work should be driven by other information.
I think the confusion of bug tracking with work tracking comes out of the bad old days where we didn't write tests and we shipped large globs of changes all at once. In that world, people spent months putting bugs in, so it makes sense they'd need a database to track them all after the release. Bugs were the majority of the work.
But I think a team with good practices that ships early and often can spend a lot more time on adding value. In which case, jamming everything into a jumped-up bug tracker is the wrong approach.
I think these are valid concerns for a project maintainer to think through for managing a chosen solution but I don't think there is a single correct solution. The "correct", or likely least bad, solution depends on the specific project and tools available.
For bug reports, always using issues for everything also requires you to evaluate how long an issue should exist before it is closed out if it can't be reproduced(if trying to keep a clean issue list). That could lead to discussion fragmentation if now new reports start coming in that need to be reported, but not just anyone can manage issue states, so a new one is created.
From a practical standpoint, they have 40 pages of open discussion in the project and 6 pages of open issues, so I get where they're coming from. The GH issue tracker is less than stellar.
I have a one bit that might be useful that I learned from debugging/optimizing Emacs.
macOS' Instruments tool only checks for leaks when it can track allocations and it is limited to ~256 stack depth. For recursive calls or very deep stacks (Emacs) some allocations aren't tracked and only after setting malloc history flags [0] I started seeing some results (and leaks).
Another place I'm investigating (for Emacs) is that AppKit lifecycle doesn't actually align with Emacs lifecycle and so leaks are happening on the AppKit and that has ZERO to do with application. Seems that problem manifests mostly on a high end specs (multiple HiDPI displays with high variable refresh rate, powerful chip etc.)
Probably nothing you haven't investigated yet, but it is similar to the ghost (pun intended) I've been looking for.
I’ve been a very happy user for 2025, with some edge cases around the terminal not working on remote shells. I haven’t seen any memory leaks, but wanted to say I appreciate this detailed response.
In my experience, the remote shell weirdness is usually because the remote shell doesn’t recognise ghostty’s TERM=xterm-ghostty value. Fixed by either copying over a terminfo with it in, or setting TERM=xterm-256color before ssh’ing: https://ghostty.org/docs/help/terminfo
I spotted Ghostty using 20GB+ memory a few days ago on MacOS (according to Activity Monitor). I went through all my tmux sessions, killed everything, it was still 20GB+ so I re-started Ghostty. If I see it happen again, I'll take some notes.
Complete speculation, but does tmux use the xterm alternative screen buffer? I can see a small bug in that causing huge memory leaks, but not showing up in testing.
On some level, that's impressive. Any idea of how long Ghostty was alive? Maybe this a new feature where Ghostty stores LLM model parameters in the terminal scrollback history? /s
Not which parts of this are sarcastic or not, but it was probably running for a few weeks. High variance on that estimate though. I was running 5+ Claude Code instances and a similar number of vim instances.
Is it possible for Ghostty to figure out how much memory its child processes (or tabs) are using? If so maybe it would help to surface this number on or near the tab itself, similar to how Chrome started doing this if you hover over a tab. It seems like many of these stem from people misinterpreting the memory number in Activity Monitor, and maybe having memory numbers on the tabs would help avoid that.
They don't have to be, but without a reproduction for maintainers, its up to the end users to provide enough information for us to track it down, and this user hasn't been able to yet.
You might want to ask your user who can reproduce it to try heaptrack. It tracks allocations, whether they leak or not. If that doesn't find anything, check the few other ways that a program can require memory, such as mmap() calls and whatever else the platform documentation tells you.
Memory usage is not really difficult to debug usually, tbh.
Valgrind won’t show you leaks where you (or a GC) still holds a reference. This could mean you’re holding on to large chunks of memory that are still referenced in a closure or something. I don’t know what language or anything about your project, but if you’re using a GC language, make sure you disable GC when running with valgrind (a common mistake). You’ll see a ton of false positives that the GC would normally clean up for you, but some of those won’t be false positives.
Its just a layer to minimize noise.
reply