AIでコードを書くのが簡単になったあと OSSはどう続いていくのか（CSS2026 OWS研究会）
2026年10月21日、コンピュータ・セキュリティ・シンポジウムCSS 2026で、Trivy作者のTeppei Fukudaさんによる「OSSとAI」という招待講演を聴いた。Trivyは、コンテナイメージなどの脆弱性や設定ミスを調べる脆弱性対応の分野では世界1著名なスキャナーだ。
trivy.dev
公式プログラムにもあるとおり、講演ではAIがOSSの参加方法や保守、コミュニティに与える変化が扱われた。
コードを書けるようになることと、そのコードを引き受けて保守できることの間には、まだ大きな距離がある。
AIによって実装の速度が上がったとき、その先にいるメンテナーの仕事はどうなるのか。利用者が増えたとき、改善や感謝、収益は作者へ戻ってくるのか。講演を通じて考えたのは、この二つだった。
報告が増えると受け取る側の仕事も増える
講演の前半では、AIによって増えるPRや脆弱性報告を、メンテナーがどう受け止めているかが語られた。
AIがコードを調べて問題を見つけ、報告文を整えてくれる。提出する側からすると、以前より少ない労力で貢献できるように見える。しかし、受け取る側には、報告を読み、再現し、影響を判断し、修正の必要性を確かめる仕事が残る。
しかも、負担になるのは誤報だけではない。同じ問題を、別々の人が似たツールで見つけ、何度も報告してくることがある。
脆弱性報告では、修正や公開時期を調整するために、非公開でやり取りすることがある。その場合、後から報告する人には、同じ内容がすでに届いているのか分からない。報告者同士には見えない重複が、メンテナーの手元に集まる。
TeppeiさんはTrivyでもこうした負担があると紹介していた。講演以前の公開Discussionでも、AI生成とみられる類似の報告が大量に届き、確認や分類に時間がかかると説明している。Linuxでも、Linus Torvaldsが2026年5月のリリース告知で、同じツールによる重複報告と、非公開であるために重複を避けにくい問題に触れていた。
さらに、Teppeiさんの判断では脆弱性に当たらない報告が、CERT/CCを経由して届いた経験も紹介された。なぜ脆弱性に当たらないのかを説明し、取り下げを求める調整にも時間がかかるという。CERT/CCには初回報告から原則45日で公開する方針があり、事情によって前後するものの、期限のある対応は受け手にとって重い。
報告を生成する時間が短くなっても、受け手が判断を終える時間まで同じように短くなるとは限らない。提出する側から見た効率化が、別の人の作業を増やすこともある。
受付の仕組みにも変化が出ている。GitHubは2026年10月1日に、非公開脆弱性報告の日次制限や、信頼する報告者の許可リストを導入した。
多くの情報を集めるために開いてきた入口を、受け手が対応できる形に調整する必要が出てきている。
OSSを支えてきた二つのフィードバック
ここから、話はOSSのコミュニティそのものへ広がっていく。Teppeiさんは、OSSには二つのフィードバックがあると説明していた。
一つは、ソフトウェアが良くなるためのフィードバックだ。誰かが使い、不具合を見つけ、報告や修正を送る。それが元のプロジェクトに取り込まれ、ほかの利用者も改善の恩恵を受ける。
もう一つは、作り続ける動機につながるフィードバックだ。使っている人から感謝される。記事で紹介される。自分の知らなかった使い方を教えてもらう。そうした反応から、誰かの役に立っていると分かる。
この二つを分けて考えると、AIによる変化が見えやすい。
たとえば、使っているライブラリに足りない機能があったとする。元のプロジェクトに相談して修正を送るほかに、必要な部分をコピーし、AIを使って自分の用途に合わせて作り直す選択がある。その後の修正も手元だけで済ませれば、元の作者に連絡せずに使い続けることもできる。
利用者にとっては合理的でも、その過程で見つかった問題や知識が、上流のプロジェクトへ戻らないことがある。
フォークや再実装自体は以前からあった。講演で印象に残ったのは、AIがそれを選びやすくすることで、改善が共有される経路まで変わるという指摘だった。
実装が増えても、改善を共有する機会や、保守を担う人とのつながりが同じだけ増えるとは限らない。各自の手元で動くものができたあと、その知識をどう共有資産へ戻すのかが問われる。
使われていても作者との接点がなくなる
もう一つの変化は、利用者と作者の間にAIが入ることだ。
AIにアプリケーションを作ってもらうと、依存するライブラリの選定や、使い方の調査までAIが進める。利用者は完成したものを使えるが、そのためにどのOSSが使われ、誰が保守しているのかを意識しないまま終わることがある。
ドキュメントを読みに行く機会が減れば、作者の考え方や関連する製品を知る機会も減る。感謝や質問を伝える相手すら、見えにくくなる。
講演では、この問題を扱った論文Vibe Coding Kills Open Sourceも紹介された。これは、利用者との直接の関わりによって作者が収益を得る条件のもとで、AI経由の利用がその関わりを弱めると、OSSの供給や品質にどう影響するかを考えた経済モデルだ。
タイトルは強い。ただ、すべてのOSSが同じように衰退すると実証した研究ではない。どのような経路で作者へ見返りが戻っているかによって、影響は変わる。
具体例として紹介されたのがTailwind CSSだった。Adam Wathanは2026年1月のコメントで、Tailwindの人気が高まる一方、ドキュメントへのアクセスは2023年初めから約40%減り、収益も約80%減ったと説明している。ドキュメントが商用製品を知ってもらう経路なので、そこへの訪問が減ることは事業の継続に響くという。
これはOSSの利用と、保守に必要な収益が別の動きをし得ることを考える具体例になる。
OSSが広く使われること、その作者が知られること、開発を続ける資金が得られること。それぞれをつないでいた経路が、AIによって変わっている。使いやすくすることに加えて、作者へ何が戻るのかも考える必要がある。
ソースの公開と貢献の受付を分けて考える
こうした変化の中で、OSSの運営方法も見直されている。
講演では、コードは公開しつつ外部PRは受け付けない方式や、Issueや利用例、設計上の知識を受け取り、実装はメンテナー側で行う方式が紹介された。開発過程は非公開にして、リリース時にソースを公開する形もある。
ここは、「オープン」という言葉に含まれるものを分けて考えると整理しやすい。
分けて考えたいこと
決める内容
ソースコードの利用条件
利用、改変、再配布などにどのような権利を認めるか
外部からの貢献
誰から、どのような提案やPRを受け付けるか
開発過程の公開
設計、テスト、議論、履歴をどこまで公開するか
利用者との接点
質問、再現例、利用報告などをどう受け取るか
Open Source Initiativeの定義は、ソースの提供や再配布、改変などの条件を定めている。誰から届いたPRでも受け付け、メンテナーがレビューすることを必須にはしていない。もちろん、ソースを読める状態にするだけでOSSになるわけでもなく、ライセンスの条件は別に確認する必要がある。
コードを公開し、利用や改変を認めながら、貢献を受け付ける手順を絞ることはできる。どこを開くと有益な情報が戻り、どこで受け手の負担が大きくなるのかを、個別に考えられる。
Trivyについての質疑でも、信頼できる貢献者に絞ってPRを受け付ける案や、Issueで先に相談し、担当を決めてからPRを作ってもらう案が挙がっていた。
背景には、同じIssueに複数のPRが届くことや、レビューしても提出者から返事がなくなることがあるという。ベンダーなどから届く有用な貢献を残しながら、最後まで対応する人と進めたいという話だった。
AIを使った人が説明と対応を引き受ける
貢献の受付方法と合わせて、講演を通して繰り返されていたのが、提出する人の理解と責任だった。
AIが書いたコードでも、PRを出す人が変更の理由を説明できるか。なぜその実装を選んだのか、どの条件で動くのか、既存の処理へどんな影響があるのか。レビューで質問されたときに、調べて答えられるか。
コードを生成して提出するところまでを自動化しても、その後の確認や修正をすべてメンテナーが引き受けるなら、相手の仕事は増えてしまう。
生成過程が見えるかどうか、という話も興味深かった。外部から届いたAI生成コードでは、どんな指示や環境で作られ、何を検証したのかが分からないことがある。自分たちで設定し、挙動を確かめてきたエージェントなら、前提を把握しやすい。生成されたコードを受け取る価値には、それを理解するための情報も関わってくる。
質疑でTeppeiさんは、提出者も変更の意図を説明できない場合、メンテナーが理解できる説明を得るまでマージしないと話していた。
現在のGhosttyのAI利用方針にも、使用したAIと関与範囲の申告に加えて、人間が変更内容とシステム全体への影響を理解し、説明できることが明記されている。
自分がここから受け取ったのは、PRを出した時点で貢献が完了するわけではない、ということだ。変更を理解し、質問に答え、必要な修正まで付き合う。その部分を誰が担うのかが、コードを書きやすくなった今ほど重要になる。
初めての貢献者の入口をどう残すか
一方で、受付を信頼できる人に絞ると、別の難しさが出てくる。
これまでの実績がある人だけを受け入れるなら、初めて貢献する人は、どこで最初の実績を作ればよいのか。
質疑では、まさにこの点が問われていた。Teppeiさんも明確な解決策があるとはしておらず、イベントやメンテナーの伴走を通じて、AIも使いながら貢献を学ぶ機会などを候補として挙げていた。
メンテナーを守るための制限と、新しく参加する人の機会。その両方を考える必要がある。
たとえば、いきなり完成したPRを送る前に、問題の再現を確認する。Issueで変更の方針を相談する。小さな調査や説明から関わり、やり取りを通じて信頼を作る。そうした入口なら、実装の量以外の形でも貢献を示せるのではないかと思った。
ただし、伴走にも時間がかかる。入口を残す仕組みを作るなら、その運営をまた少数のメンテナーに背負わせない方法まで考えたい。
まとめ
セキュリティツールで多くの問題を検出できた。修正PRを自動で作れた。
そこまでできると、成果が出たように感じやすい。
でも、受け取った人が重複を調べ直し、誤報かどうかを確認し、変更の意図を読み解く必要があるなら、その人の仕事はどれだけ減ったのだろう。
検出結果を渡すなら、どの条件で問題になるのか、何を根拠にそう判断したのかまで伝えたい。修正案なら、変更の理由と検証結果を揃えたい。新しい情報を増やすことと同じくらい、受け手が判断を終えられるようにすることを考える必要がある。
これはツールの機能にも、自分自身の貢献の仕方にも返ってくる問いだと思う。
Teppeiさんは、失われつつあるフィードバックをどう取り戻すかについて、まだ答えはないとしたうえで、新しい仕組みやツールを作る機会にも触れていた。
自分も、AIによって作れるものが増えることを楽しみたい。そのとき、受け取る人が理解できる説明を添えること、使っているOSSへ改善や感謝を返すこと、次の人が参加できる入口を残すことまで、一緒に考えていきたい。
コードを作りやすくなった今、そのコードを支える人と、支えるためのやり取りに、もう少し目を向けたい。
ここまで読んでいただいた方は、当ブログ筆者である佐田淳史のOWS研究会・招待講演もぜひご覧になってください。私の講演では、AIが発展してきたけど今後どうしていく？の一案について話しています。
speakerdeck.com
youtube.com
@_buf @yongfook In search.
Since march.
ghostty#11159
2 likes · 26 views
First really severe frustration I've encountered since switching to ghostty about a year ago.
@mitchellh Please can we have a fix/opt-out. Opening python files in @zeddotdev is not dangerous.
ghostty#13904
15 likes · 2,653 views
Ghostty 里中文插字会吃掉后面一个字，抓到是微信输入法多发了个 Delete
前段时间在 Ghostty 里用中文输入法时发现，光标停在文字中间打中文，后面那个字会一个接一个消失。跟覆盖模式、跟什么切换快捷键都没关系，一直没有找到原因，昨天实在受不了了，专门花了几分钟来试了下，最终发现：
微信输入法的「中文与英文/数字之间自动加空格」补完那个空格之后，又替终端发了一个 Delete ； Ghostty 按物理键码解释这个事件，下发的就是"删掉光标右边一个字符"。
所以只有 Ghostty 掉字，iTerm2 、TextEdit 、Sublime 、Tabby 都正常。
但是在行尾打就不会出事，多打几个空格把位置占出来也不会，可有时候怎么打都没事。为了这个"时好时坏"，我一开始以为是某个快捷键的问题，还到处去找的那个以为的切换键，结果根本没有这么个东西。
后来换输入法一试就清楚了：百度五笔完全正常，微信输入法必现。
两者唯一的差别就是自动加空格。这个空格要生效，终端得把光标周围的文本告诉输入法。kitty 不告诉，所以在 kitty 里这功能一个空格都不加； Ghostty 和 iTerm2 告诉，空格就来了。
猜不出来，我写了个三十行的小工具，在 Ghostty 里裸读 stdin ，把每个字节按十六进制记下来。
复现序列：先打 12345678，左箭头按四次，打 dd，切中文打 在在，最后再打一个 d。
关键的几行：
e5 9c a8 20 "在 " 一次提交（自动空格）
20 64 " d" 一次提交（自动空格）
1b 5b 33 7e CSI 3~ ← 32ms 后，我没按
1b 5b 33 7e CSI 3~ ← 27ms 后，我没按
同一次测试里我自己按退格，进来的是裸的 7f，跟 1b 5b 33 7e 不同源。最终缓冲区是 1234dd 在在在 dd678，5 真没了，不是显示问题。
通过 AI 分析，macOS 上 117 号键码是 Delete （前向删除），Ghostty 的键码表把 117 映射到内部 delete ，编码成 CSI 3 波浪号。它判断"你按的哪个键"用的是物理键码，事件里那个 7f 文本不参与。AppKit 的原生文本视图反过来，用 characters 字段查键位绑定，7f 落到 deleteBackward ； Tabby （ Electron ）直接把控制字符丢掉。同一个事件里，只有按物理键码解释的那个会去删右边的字。
Ghostty 这边其实有一道防护 shouldSuppressComposingControlInput，但它只拦"组字中"且"字符小于 0x20"的情况。这次的删除发生在上屏之后、带的是 0x7f，两个条件都不满足，就漏过去了。
日志重放一遍还能看出为什么时好时坏：第一次 Delete 落下时，光标右边正好是上一次提交留下的空格，吃掉的是空格，屏幕上没感觉；第二次右边是 5，就少一个字。所以掉不掉，只看光标右边那个位置是不是空格。那个"多打几个空格留位"的偏方，也就是把要被吃掉的东西提前摆好了。
关掉微信输入法的「中文与英文/数字之间自动加空格」，或者换个没这特性的输入法，就没有这个问题了。
准备去 github 提个 issue ，发现在 10 月 16 号已经有人提过同症状的讨论（微信输入法下光标前移再打中文会覆盖后面的文字），零回复。应该还没有处理了，先给贴个过程证据，希望早上修复，可围观： ghostty#14732
有同样问题的可以回个帖，我把探针脚本贴上来，你自己跑一遍就知道是不是同一个原因。
4 comments
How to Install Ghostty 1.4 on Linux and macOS (On Ubuntu 24.04, Use Flatpak)
Ghostty 1.4 is out, and if you're on Ubuntu 24.04 LTS, apt install ghostty won't get it for you. The release requires GTK 4.18 and libadwaita 1.7, the release notes say outright that 24.04 doesn't meet that, and Ghostty exits at startup if it loads older libraries. The notes offer two ways out: stay on an older Ghostty, or use the Flatpak.
That's awkward, because 1.4 is the release that makes the "should I switch terminals?" question worth asking again. It took seven months, 2,889 commits and 172 contributors. The fixes are the kind you notice: scrollback memory down 70–90%, plain ASCII parsing up from 128 MB/s to 725 MB/s, and on Linux, text that is finally sharp at fractional scaling. The Hacker News thread passed 1,000 points.
This post covers the changes you'll feel day to day, install and upgrade steps for macOS, Fedora, Arch and Ubuntu (24.04 included), the config lines that break on upgrade, and moving over from iTerm2, Kitty or Alacritty.
What's new in Ghostty 1.4 that you'll actually notice
I went through the full changelog, and these are the changes that show up in a normal working day. All numbers are the maintainers' own, from the release notes.
| Change | Before | 1.4 |
|---|---|---|
| Default scrollback limit | 10 MB | 50 MB |
| Physical memory for off-screen scrollback | uncompressed | 70–90% less (macOS, 64-bit Linux) |
| Page memory per new terminal (macOS) | 128 KiB | ~16 KiB |
| GPU memory, 20 hidden tabs (macOS) | ~385 MiB | ~18 MiB |
| Plain ASCII parsing | 128 MB/s | 725 MB/s |
| cat of a 150 MB file (macOS) | 1.5 s | 566 ms |
| Resize with large scrollback | baseline | ~6x faster |
To me the memory numbers matter more than the throughput ones. Nobody cats 150 MB files all day, but plenty of us have 30 tabs open with a week of build logs in scrollback. The default scrollback limit went up fivefold and the memory bill still went down.
The rest of what I'd care about:
- A new OpenGL renderer on GTK. It drops GtkGLArea and renders with EGL on its own thread, exporting DMABUF frames with triple buffering. This fixes the blurry text at fractional scales (#1938). If you run a laptop at 125% or 150%, this alone is reason enough to upgrade.
- ghostty +ssh is a drop-in ssh wrapper that installs Ghostty's terminfo on the remote host and falls back to TERM=xterm-256color. It deals with the old "unknown terminal type xterm-ghostty" problem on servers you don't control.
- Split drag and drop on GTK, controlled by the new drag-handle option (auto, always, never).
- Full Kitty graphics support, now with animation and relative placements. The project calls Ghostty the first terminal outside Kitty to do this.
- macOS 27 fixes for the tab bar and titlebar. It still runs back to macOS 13, and launch to a window is about 15% faster.
The release also fixes ten security advisories. The one that concerns me most is GHSA-4hwh-wx3w-3fqg: paste protection didn't treat carriage returns as line endings, so a pasted command could run without confirmation in programs that don't use bracketed paste. Two of the advisories name 1.3.0 and 1.3.1 as affected, and I couldn't find a 1.3.2 patch release. Neither could hongminhee on Lobsters, who pointed out that getting the fixes means taking the GTK 4.18 bump and the new defaults along with them. That's a fair complaint, and it's why this post opens with Ubuntu 24.04.
How to install Ghostty 1.4 on macOS
macOS is the only platform with official prebuilt binaries. Get the DMG from ghostty.org or use the community Homebrew cask, which repackages the same DMG:
brew install --cask ghostty
# already installed?
brew upgrade --cask ghostty
If you installed from the DMG, the built-in updater handles it. In 1.4, auto-installed updates no longer prompt you to restart.
How to install Ghostty 1.4 on Linux (Fedora, Arch, Ubuntu and others)
There are no official Linux binaries. Every package below is built by a distro maintainer or a community volunteer, and each one updates on its own schedule. Check the version before you assume you have 1.4:
ghostty --version
On Fedora, use the community COPR:
sudo dnf copr enable scottames/ghostty
sudo dnf install ghostty
On Arch it's in [extra], which tracks tagged releases:
sudo pacman -S ghostty
Ubuntu 26.04 and later has Ghostty in the official repos, but the PPA README listed that package as 1.3.0 in May 2026, so check before you trust it. The mkasberg/ghostty-ubuntu PPA is usually ahead:
sudo add-apt-repository ppa:mkasberg/ghostty-ubuntu
sudo apt update
sudo apt install ghostty
When I checked, the PPA was still on 1.3.1. Its README lists Ubuntu 24.04 support as "up to Ghostty 1.3.1", so that route tops out at 1.3.1 on 24.04.
openSUSE, Gentoo, Void, Alpine, Solus and NixOS use zypper in ghostty, emerge -av ghostty, xbps-install ghostty, apk add ghostty (testing), eopkg install ghostty, and pkgs.ghostty. They're all listed on the official install page.
For anything else there's snap install ghostty --classic, or the community AppImage, which runs as ./Ghostty-${VERSION}-${ARCH}.AppImage after a chmod +x.
How to run Ghostty 1.4 on Ubuntu 24.04 LTS
1. Flatpak. It's the workaround the release notes name, and Flatpak apps run on their own runtime instead of the system GTK. I'd start here.
2. AppImage or Snap. Neither project says whether it gets around the GTK 4.18 floor, so read the AppImage's troubleshooting doc before you depend on it.
3. Stay on 1.3.1. The release notes list this as the other option, but you keep the advisories that affect 1.3.x.
4. Upgrade to 26.04. That should clear the GTK floor, but you still need a 1.4 package from somewhere, and the repo and PPA versions above lag.
Building from source on 24.04 doesn't help either. The release notes say builds against older GTK headers fail at compile time.
Building 1.4 from source
The build page was missing two things when I wrote this. Ghostty 1.4 needs Zig 0.17, and the build page still lists 0.15.2 for "1.3.x and tip". There's also a new -Dinstalled-exe-path option. Gingeh reported that leaving it out breaks the systemd unit for ~/.local installs:
tar -xf ghostty-1.4.0.tar.gz && cd ghostty-1.4.0/
zig build -p $HOME/.local -Doptimize=ReleaseFast \
-Dinstalled-exe-path=$HOME/.local/bin/ghostty
Use the tarball from release.files.ghostty.org. GitHub's auto-generated "Source code" archive is missing preprocessed files.
Upgrading from 1.3: config lines that will bite you
Read this before you upgrade, because two of the default changes are going to annoy people.
# macOS: copy-on-select now defaults to none (was true), so middle-click
# paste of the selection stops working. Restore 1.3 behavior with primary.
# An explicit "true" now copies to the system clipboard instead.
copy-on-select = primary
# copy-on-select = clipboard now copies ONLY to the system clipboard.
# For the old behavior, use:
# copy-on-select = both
# scrollback-limit was renamed (old name still works via a compat layer):
scrollback-limit-bytes = 50000000
# macOS: cmd+up/down went back to jump_to_prompt. Want scrolling?
keybind = cmd+arrow_up=scroll_to_top
keybind = cmd+arrow_down=scroll_to_bottom
On GTK, ctrl+shift+page_up/page_down now run move_tab, and jump_to_prompt moved to ctrl+shift+arrow_up/down. If a TUI you use needs those keys, unbind them.
Run ghostty +show-config after upgrading to see what's actually in effect. The new +explain-config documents any option from the command line.
Migrating from iTerm2, Kitty or Alacritty
The config file lives at ~/.config/ghostty/config.ghostty on both platforms. On macOS, ~/Library/Application Support/com.mitchellh.ghostty/config.ghostty also loads, after the XDG file, so it wins on conflicts. Reload with cmd+shift+, on macOS or ctrl+shift+, on Linux.
| What | Kitty (kitty.conf) | Alacritty (alacritty.toml) | Ghostty |
|---|---|---|---|
| Font | font_family JetBrains Mono | [font.normal] family = "JetBrains Mono" | font-family = JetBrains Mono |
| Size | font_size 13.0 | [font] size = 13.0 | font-size = 13 |
| Opacity | background_opacity 0.9 | [window] opacity = 0.9 | background-opacity = 0.9 |
| Padding | window_padding_width 8 | [window.padding] x = 8 | window-padding-x = 8 |
| Key | map ctrl+shift+t new_tab | [[keyboard.bindings]] | keybind = ctrl+shift+t=new_tab |
Coming from iTerm2, there's no import, and iTerm2's settings live in a plist, so you'll be retyping. Set macos-option-as-alt = true if you used Option as Meta, and try Ghostty's quick terminal as a stand-in for the hotkey window. If you rely on tmux -CC integration, keep iTerm2 installed. Commenters in the HN thread who want it say Ghostty doesn't have tmux control mode yet.
For Kitty users, the gap that came up on HN is hints mode. One commenter called it "the one feature keeping me from switching." Ghostty doesn't have an equivalent upstream yet, so if you live in hints mode, that may decide it for you.
From Alacritty, you gain tabs and splits without needing tmux. You keep a plain-text config, though it isn't TOML.
So, is it time to switch?
On macOS, I'd say yes. iTerm2 does more, but Ghostty is the faster native app, and 1.4 addresses the memory bloat from lots of tabs that used to be a fair criticism. On Linux it depends on your distro more than on Ghostty. Fedora and Arch ship a new enough GTK, so the upgrade is clean once the packages move: when I checked, Arch had 1.4.0 in extra-testing and the scottames COPR was still on 1.3.1. Ubuntu 24.04 users get a Flatpak or a security backlog. The project runs a six-month release cycle with 1.5 planned for March 2027, and there's been no 1.3.x patch release for the advisories. I'd like to see that change.
Ghostty, Kitty, WezTerm or iTerm2: what's your daily terminal, and what would actually make you switch? And if you're running 1.4 on 24.04 through the Flatpak, AppImage or Snap, tell me which one worked.
Sources
- Ghostty 1.4.0 release notes
- Ghostty install docs (binaries)
- Ghostty build docs
- Ghostty config docs
- mkasberg/ghostty-ubuntu
- pkgforge-dev/ghostty-appimage
- Hacker News discussion
- Lobsters discussion
终端历史一多就吃内存，翻旧输出还卡？
ghostty 是 GPU 加速原生终端：1.4 版历史压缩省内存，纯文本解析快 5.7 倍，默认历史上限也从 10MB 提到了 50MB。
对终端常驻几十个窗口的人来说，历史压缩比加内存条实在。
你会先拿它换掉哪个终端？
#终端 #开源 @grok
ghostty-org/ghostty
7 likes · 305 views
I have a fix in my fork: github.com/ghostty-org/ghostty/commit/95c7fc32280…
Inspect + build yourself
Ghostty 1.4.0 completa el protocolo Kitty y parcha 10 fallos de seguridad
Ghostty 1.4.0 ya deja animar imágenes Kitty completas, algo que ningún otro terminal fuera de Kitty había logrado hasta hoy.
La versión, publicada el 27 de octubre de 2026 por el equipo de Mitchell Hashimoto, suma siete meses de trabajo, 172 colaboradores y 2.889 commits, además de diez correcciones de seguridad.
TL;DR
- Ghostty 1.4.0, publicado el 27 de octubre de 2026, completa el protocolo de gráficos Kitty con animación.- El emulador es el primer terminal fuera de Kitty en soportar placements relativos de imágenes.- La versión corrige 10 avisos de seguridad, incluidos fallos en el pegado y en el modo de control de tmux.- macOS 27 (Golden Gate) ya funciona sin los defectos visuales que tenía la beta 1.3.1.- Siete meses de desarrollo y 172 colaboradores producen 2.889 commits en este ciclo.
Qué es Ghostty
Ghostty es un emulador de terminal de código abierto escrito en Zig, creado por Mitchell Hashimoto, cofundador de HashiCorp, y lanzado públicamente en 2024. Renderiza con la GPU del sistema y usa los widgets nativos de cada plataforma en vez de Electron. La versión más reciente, Ghostty 1.4.0, añade el protocolo de gráficos Kitty completo.
El proyecto gana terreno frente a alternativas como iTerm2, Windows Terminal o Alacritty gracias a su renderizado por GPU y a funciones pensadas para terminales modernas: integración con shells vía SSH, soporte de temas Nerd Font y, desde esta versión, un protocolo de gráficos completo. Ghostty corre en Linux y macOS, y se instala mediante gestores de paquetes nativos como Homebrew, pacman o los repositorios de cada distribución.
Qué pasó con Ghostty 1.4.0
El equipo publicó la nueva release de Ghostty el 27 de octubre de 2026, tras siete meses de trabajo con 172 colaboradores y 2.889 commits. La lista de cambios cubre tres frentes: soporte para macOS 27 (nombre interno Golden Gate), el cierre total del protocolo de gráficos Kitty y diez correcciones de seguridad.
En macOS 27, las pestañas en la barra de título (con macos-titlebar-style = tabs) vuelven a alinearse correctamente, la barra de pestañas nativa ya no se dibuja como una franja gris sólida sobre el tema del usuario, y macos-titlebar-style = hidden deja de tapar las primeras líneas de la terminal cuando el sistema tiene activado Reducir transparencia. El ícono de la aplicación perdió también un borde delgado que arrastraba desde versiones anteriores. El terminal escrito en Zig sigue siendo compatible con versiones anteriores, desde macOS 13 (Ventura) en adelante.
Más allá de los titulares, las notas detallan mejoras de integración con SSH (el terminal reenvía mejor variables de entorno y configuración de temas al conectarse a un servidor remoto) y una reducción general del uso de memoria en sesiones largas con muchas pestañas abiertas. El equipo también resolvió decenas de reportes menores de renderizado acumulados desde la versión 1.3.1.
El ciclo sumó 2.889 commits de 172 colaboradores en siete meses de desarrollo.
Contexto e historia del proyecto
Mitchell Hashimoto, conocido por fundar HashiCorp (creador de Terraform y Vagrant), presentó Ghostty en público en 2024 tras años de desarrollo privado. El objetivo declarado fue construir una terminal rápida, multiplataforma y con soporte nativo de GPU, sin depender de frameworks como Electron. Desde entonces el proyecto pasó por las versiones 1.0 a 1.3.1, sumando funciones como integración con tmux, mejoras de SSH y soporte parcial del protocolo de gráficos de Kitty.
La elección de Zig no es casual: el lenguaje compila a binarios pequeños, no depende de un recolector de basura y facilita el control fino de memoria que un emulador de terminal necesita para dibujar miles de celdas de texto por segundo sin saturar la GPU. Esa base técnica es la que permitió, en esta release, bajar el consumo de memoria sin sacrificar funciones.
Ese soporte parcial del protocolo de gráficos generó fricción. Ghostty 1.3.0 y 1.3.1 quedaron expuestos a un fallo (GHSA-hcr9-7hcr-mjm8) que permitía cerrar todas las ventanas abiertas con solo mostrar texto malicioso en modo de control de tmux, sin que tmux estuviera siquiera instalado. La versión 1.4.0 corrige ese fallo y uno relacionado con paneles de tamaño cero (GHSA-hp9c-qp4q-cpw3), ambos heredados de esas dos versiones.
Detalles técnicos: cómo funciona el protocolo Kitty completo
El protocolo de gráficos de Kitty permite que un programa de terminal transmita datos de imagen directamente al emulador mediante secuencias de escape APC, en vez de depender del servidor gráfico del sistema. El programa envía la imagen en fragmentos codificados en base64, el terminal los decodifica, compone el resultado sobre la cuadrícula de texto y lo muestra en la posición indicada. Hasta la versión 1.3.1, Ghostty soportaba la transmisión de imágenes estáticas pero no la animación ni las posiciones relativas.
La animación añade un paso más: el programa transmite varios cuadros con metadatos de temporización y composición, y el terminal se encarga de reproducirlos en orden, calcular cuándo pausar la animación si la pestaña pierde el foco, y liberar la memoria de los cuadros que ya no se necesitan. Las posiciones relativas permiten anclar una imagen «hija» a la colocación de otra imagen «padre»: si el programa mueve la imagen padre, la hija se mueve con ella sin que el programa tenga que recalcular coordenadas en cada fotograma.
sequenceDiagram
participant P as Programa
participant T as Ghostty
P->>T: transmite cuadro de imagen (APC)
T-->>P: confirma recepción
Note over P,T: se repite por cada cuadro de la animación
P->>T: indica orden de reproducción
T-->>P: reproduce y pausa si la pestaña pierde foco
El equipo también hizo una pasada de conformidad completa contra la especificación y contra el propio Kitty, corrigiendo decenas de diferencias de comportamiento. Por ejemplo, ahora las imágenes se desplazan junto con el texto dentro de regiones de scroll, y retransmitir un ID de imagen reemplaza la imagen anterior en lugar de duplicarla.
En la práctica, las posiciones relativas sirven para programas que dibujan gráficos compuestos: un visor de imágenes puede mostrar una miniatura flotante sobre la imagen principal, o una herramienta de monitoreo puede superponer un ícono de estado sobre un gráfico más grande, todo sin recalcular coordenadas absolutas en cada fotograma.
El cambio se nota con cualquier programa que use el protocolo. Por ejemplo, mostrar un GIF animado con kitten icat:
kitten icat logo-animado.gif
Antes de la versión 1.4.0, Ghostty mostraba solo el primer cuadro del GIF. Con esta release, el GIF se reproduce completo y se pausa automáticamente si cambiás de pestaña.
Ghostty es el primer terminal fuera de Kitty con el protocolo de gráficos completo, según sus notas de versión.
Impacto y seguridad: diez fallos corregidos
Más allá de las imágenes animadas, la versión 1.4.0 del proyecto cierra diez avisos de seguridad. La mayoría requiere interacción del usuario (pegar texto, hacer cmd-click en un enlace, arrastrar y soltar o confirmar un diálogo): no son fallos explotables de forma remota y silenciosa. Entre los más relevantes, un error en la protección de pegado que no trataba los retornos de carro como fin de línea permitía ejecutar un comando sin confirmación en programas que no usan «bracketed paste» (GHSA-4hwh-wx3w-3fqg). También se corrigieron comandos maliciosos del protocolo de gráficos que podían colgar el programa, forzar asignaciones de memoria enormes o, en casos limitados, leer o borrar archivos fuera de los directorios temporales permitidos (GHSA-mhff-mv4q-fp63).
AvisoPlataformaCómo se activaImpactoGHSA-4hwh-wx3w-3fqgTodasPegar texto con retornos de carroEjecuta un comando sin confirmaciónGHSA-mhff-mv4q-fp63TodasMostrar un comando de gráficos maliciosoCuelgue, asignación masiva de memoria o lectura/borrado de archivos limitadoGHSA-hcr9-7hcr-mjm81.3.0 y 1.3.1Mostrar salida en modo de control de tmuxCierra todas las ventanasGHSA-cw69-wm67-5pv8macOSCmd-click en un enlace OSC 8 manipuladoAbre archivos locales o esquemas de URL inseguros
El resto de los avisos corregidos incluye un error que corrompía memoria al limpiar la pantalla hacia el scrollback con un límite de buffer configurado en cero (GHSA-w9q4-5jvv-mcv4), y uno que permitía que el nombre de un directorio clonado desde un repositorio no confiable disparara secuencias de escape arbitrarias a través de la integración con zsh o bash, por ejemplo para reemplazar el contenido del portapapeles (GHSA-2r63-vmw6-3m3c). En macOS, abrir un archivo cuyo nombre contiene caracteres de control podía ejecutar un comando distinto al que mostraba el diálogo de confirmación (GHSA-mxqx-236q-wrv7).
Un detalle curioso: el mantenedor principal pidió números CVE para estos avisos semanas antes del lanzamiento, pero GitHub todavía no los había asignado al momento de publicar las notas. Es un recordatorio de que el identificador CVE y el aviso de seguridad real no siempre llegan al mismo tiempo.
> 📌 Nota: ninguno de los diez avisos de Ghostty 1.4.0 tiene todavía un número CVE formal asignado; el proyecto solo publicó los identificadores GHSA de GitHub.
Qué sigue para el emulador de terminal Ghostty
El proyecto no publicó un calendario fijo para la próxima versión, pero el patrón de los últimos ciclos (de 1.3.0 a 1.4.0 pasaron siete meses) sugiere que la 1.5 no llegaría antes de mediados de 2027. Es de esperar que las correcciones de seguridad reciban números CVE retroactivos una vez GitHub los asigne, y que el equipo siga puliendo la integración con SSH que esta release ya mejoró.
El salto de contribuciones, 172 personas distintas en un solo ciclo, también es un dato relevante para un proyecto que recién cumplió dos años desde su lanzamiento público: sugiere que la comunidad alrededor del terminal escrito en Zig sigue creciendo en vez de depender solo de su autor original.
Una limitación que se mantiene: Ghostty no tiene soporte nativo para Windows, algo que lo deja fuera de las opciones para equipos que trabajan exclusivamente en ese sistema. Para esos casos, alternativas como Windows Terminal o WezTerm siguen siendo la opción más directa.
📖 Resumen en Telegram: Ver resumen
Probalo vos: si ya usás Ghostty, actualizá con brew upgrade ghostty en macOS o con el paquete de tu distribución en Linux, y corré kitten icat sobre un GIF animado para ver el protocolo de gráficos completo en acción.
Preguntas frecuentes
¿Qué es el protocolo de gráficos de Kitty que ahora soporta Ghostty por completo?
Es un sistema de secuencias de escape que permite a un programa de terminal transmitir y animar imágenes directamente, sin pasar por el servidor gráfico del sistema. Ghostty 1.4.0 es el primer terminal fuera de Kitty en implementarlo al 100%, incluida la animación.
¿Ghostty es gratuito y de código abierto?
Sí. El emulador de terminal se distribuye bajo una licencia de código abierto y su código fuente está disponible en GitHub, igual que el historial completo de cambios de cada versión.
¿Qué versiones de macOS soporta la nueva release de Ghostty?
Desde macOS 13 (Ventura) en adelante, incluido el recién llegado macOS 27 (Golden Gate), con correcciones específicas de compatibilidad visual para este último.
¿Los fallos de seguridad corregidos en Ghostty requieren actualizar de inmediato?
La mayoría exige que la víctima interactúe (pegar texto, hacer clic o confirmar un diálogo), así que el riesgo no es de ejecución remota silenciosa, pero sigue siendo recomendable actualizar cuanto antes porque varios avisos afectan a usuarios sin que lo noten, como al clonar un repositorio con un nombre de directorio manipulado.
¿Qué lenguaje de programación usa el terminal escrito en Zig?
Ghostty está escrito en Zig, un lenguaje de bajo nivel pensado para rendimiento y control de memoria sin un recolector de basura, lo que explica parte de las mejoras de memoria que trae esta versión.
Referencias
- ghostty.org: notas de la versión 1.4.0 con el changelog completo y los avisos de seguridad.- GitHub: repositorio oficial del código fuente de Ghostty.- Kitty graphics protocol: especificación oficial del protocolo de gráficos que Ghostty ahora implementa por completo.- GHSA-4hwh-wx3w-3fqg: aviso de seguridad sobre la protección de pegado y los retornos de carro.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
I actually fixed one cause of this, which is released in 1.4.0.
ghostty#12714
The only other cause I've encountered is if a secure input (password) field is focused, since macOS won't give apps global keyboard events for obvious reasons. If you focus a normal text input, it should start working again.
I have noticed where macOS doesn't properly release its reference to a Secure Input properly. I've documented how to determine if this is the cause here: ghostty#11883
Ghostty + tmux 쓰는 분들에게. 어제 나온 Ghostty 1.4에서 tmux extended-keys 켜두면 한글 입력 상태에서 Ctrl-U 같은 키가 안 먹습니다 Ctrl-ㅕ로 받거든요. 당장은 extended-keys off 말곤 방법이 없고, 이 PR 이후 생긴 문제입니다. ghostty#14144
8 likes · 2 reposts · 447 views
Mentions
AIでコードを書くのが簡単になったあと OSSはどう続いていくのか（CSS2026 OWS研究会） 2026年10月21日、コンピュータ・セキュリティ・シンポジウムCSS 2026で、Trivy作者のTeppei Fukudaさんによる「OSSとAI」という招待講演を聴いた。Trivyは、コンテナイメージなどの脆弱性や設定ミスを調べる脆弱性対応の分野では世界1著名なスキャナーだ。 trivy.dev 公式プログラムにもあるとおり、講演ではAIがOSSの参加方法や保守、コミュニティに与える変化が扱われた。 コードを書けるようになることと、そのコードを引き受けて保守できることの間には、まだ大きな距離がある。 AIによって実装の速度が上がったとき、その先にいるメンテナーの仕事はどうなるのか。利用者が増えたとき、改善や感謝、収益は作者へ戻ってくるのか。講演を通じて考えたのは、この二つだった。 報告が増えると受け取る側の仕事も増える 講演の前半では、AIによって増えるPRや脆弱性報告を、メンテナーがどう受け止めているかが語られた。 AIがコードを調べて問題を見つけ、報告文を整えてくれる。提出する側からすると、以前より少ない労力で貢献できるように見える。しかし、受け取る側には、報告を読み、再現し、影響を判断し、修正の必要性を確かめる仕事が残る。 しかも、負担になるのは誤報だけではない。同じ問題を、別々の人が似たツールで見つけ、何度も報告してくることがある。 脆弱性報告では、修正や公開時期を調整するために、非公開でやり取りすることがある。その場合、後から報告する人には、同じ内容がすでに届いているのか分からない。報告者同士には見えない重複が、メンテナーの手元に集まる。 TeppeiさんはTrivyでもこうした負担があると紹介していた。講演以前の公開Discussionでも、AI生成とみられる類似の報告が大量に届き、確認や分類に時間がかかると説明している。Linuxでも、Linus Torvaldsが2026年5月のリリース告知で、同じツールによる重複報告と、非公開であるために重複を避けにくい問題に触れていた。 さらに、Teppeiさんの判断では脆弱性に当たらない報告が、CERT/CCを経由して届いた経験も紹介された。なぜ脆弱性に当たらないのかを説明し、取り下げを求める調整にも時間がかかるという。CERT/CCには初回報告から原則45日で公開する方針があり、事情によって前後するものの、期限のある対応は受け手にとって重い。 報告を生成する時間が短くなっても、受け手が判断を終える時間まで同じように短くなるとは限らない。提出する側から見た効率化が、別の人の作業を増やすこともある。 受付の仕組みにも変化が出ている。GitHubは2026年10月1日に、非公開脆弱性報告の日次制限や、信頼する報告者の許可リストを導入した。 多くの情報を集めるために開いてきた入口を、受け手が対応できる形に調整する必要が出てきている。 OSSを支えてきた二つのフィードバック ここから、話はOSSのコミュニティそのものへ広がっていく。Teppeiさんは、OSSには二つのフィードバックがあると説明していた。 一つは、ソフトウェアが良くなるためのフィードバックだ。誰かが使い、不具合を見つけ、報告や修正を送る。それが元のプロジェクトに取り込まれ、ほかの利用者も改善の恩恵を受ける。 もう一つは、作り続ける動機につながるフィードバックだ。使っている人から感謝される。記事で紹介される。自分の知らなかった使い方を教えてもらう。そうした反応から、誰かの役に立っていると分かる。 この二つを分けて考えると、AIによる変化が見えやすい。 たとえば、使っているライブラリに足りない機能があったとする。元のプロジェクトに相談して修正を送るほかに、必要な部分をコピーし、AIを使って自分の用途に合わせて作り直す選択がある。その後の修正も手元だけで済ませれば、元の作者に連絡せずに使い続けることもできる。 利用者にとっては合理的でも、その過程で見つかった問題や知識が、上流のプロジェクトへ戻らないことがある。 フォークや再実装自体は以前からあった。講演で印象に残ったのは、AIがそれを選びやすくすることで、改善が共有される経路まで変わるという指摘だった。 実装が増えても、改善を共有する機会や、保守を担う人とのつながりが同じだけ増えるとは限らない。各自の手元で動くものができたあと、その知識をどう共有資産へ戻すのかが問われる。 使われていても作者との接点がなくなる もう一つの変化は、利用者と作者の間にAIが入ることだ。 AIにアプリケーションを作ってもらうと、依存するライブラリの選定や、使い方の調査までAIが進める。利用者は完成したものを使えるが、そのためにどのOSSが使われ、誰が保守しているのかを意識しないまま終わることがある。 ドキュメントを読みに行く機会が減れば、作者の考え方や関連する製品を知る機会も減る。感謝や質問を伝える相手すら、見えにくくなる。 講演では、この問題を扱った論文Vibe Coding Kills Open Sourceも紹介された。これは、利用者との直接の関わりによって作者が収益を得る条件のもとで、AI経由の利用がその関わりを弱めると、OSSの供給や品質にどう影響するかを考えた経済モデルだ。 タイトルは強い。ただ、すべてのOSSが同じように衰退すると実証した研究ではない。どのような経路で作者へ見返りが戻っているかによって、影響は変わる。 具体例として紹介されたのがTailwind CSSだった。Adam Wathanは2026年1月のコメントで、Tailwindの人気が高まる一方、ドキュメントへのアクセスは2023年初めから約40%減り、収益も約80%減ったと説明している。ドキュメントが商用製品を知ってもらう経路なので、そこへの訪問が減ることは事業の継続に響くという。 これはOSSの利用と、保守に必要な収益が別の動きをし得ることを考える具体例になる。 OSSが広く使われること、その作者が知られること、開発を続ける資金が得られること。それぞれをつないでいた経路が、AIによって変わっている。使いやすくすることに加えて、作者へ何が戻るのかも考える必要がある。 ソースの公開と貢献の受付を分けて考える こうした変化の中で、OSSの運営方法も見直されている。 講演では、コードは公開しつつ外部PRは受け付けない方式や、Issueや利用例、設計上の知識を受け取り、実装はメンテナー側で行う方式が紹介された。開発過程は非公開にして、リリース時にソースを公開する形もある。 ここは、「オープン」という言葉に含まれるものを分けて考えると整理しやすい。 分けて考えたいこと 決める内容 ソースコードの利用条件 利用、改変、再配布などにどのような権利を認めるか 外部からの貢献 誰から、どのような提案やPRを受け付けるか 開発過程の公開 設計、テスト、議論、履歴をどこまで公開するか 利用者との接点 質問、再現例、利用報告などをどう受け取るか Open Source Initiativeの定義は、ソースの提供や再配布、改変などの条件を定めている。誰から届いたPRでも受け付け、メンテナーがレビューすることを必須にはしていない。もちろん、ソースを読める状態にするだけでOSSになるわけでもなく、ライセンスの条件は別に確認する必要がある。 コードを公開し、利用や改変を認めながら、貢献を受け付ける手順を絞ることはできる。どこを開くと有益な情報が戻り、どこで受け手の負担が大きくなるのかを、個別に考えられる。 Trivyについての質疑でも、信頼できる貢献者に絞ってPRを受け付ける案や、Issueで先に相談し、担当を決めてからPRを作ってもらう案が挙がっていた。 背景には、同じIssueに複数のPRが届くことや、レビューしても提出者から返事がなくなることがあるという。ベンダーなどから届く有用な貢献を残しながら、最後まで対応する人と進めたいという話だった。 AIを使った人が説明と対応を引き受ける 貢献の受付方法と合わせて、講演を通して繰り返されていたのが、提出する人の理解と責任だった。 AIが書いたコードでも、PRを出す人が変更の理由を説明できるか。なぜその実装を選んだのか、どの条件で動くのか、既存の処理へどんな影響があるのか。レビューで質問されたときに、調べて答えられるか。 コードを生成して提出するところまでを自動化しても、その後の確認や修正をすべてメンテナーが引き受けるなら、相手の仕事は増えてしまう。 生成過程が見えるかどうか、という話も興味深かった。外部から届いたAI生成コードでは、どんな指示や環境で作られ、何を検証したのかが分からないことがある。自分たちで設定し、挙動を確かめてきたエージェントなら、前提を把握しやすい。生成されたコードを受け取る価値には、それを理解するための情報も関わってくる。 質疑でTeppeiさんは、提出者も変更の意図を説明できない場合、メンテナーが理解できる説明を得るまでマージしないと話していた。 現在のGhosttyのAI利用方針にも、使用したAIと関与範囲の申告に加えて、人間が変更内容とシステム全体への影響を理解し、説明できることが明記されている。 自分がここから受け取ったのは、PRを出した時点で貢献が完了するわけではない、ということだ。変更を理解し、質問に答え、必要な修正まで付き合う。その部分を誰が担うのかが、コードを書きやすくなった今ほど重要になる。 初めての貢献者の入口をどう残すか 一方で、受付を信頼できる人に絞ると、別の難しさが出てくる。 これまでの実績がある人だけを受け入れるなら、初めて貢献する人は、どこで最初の実績を作ればよいのか。 質疑では、まさにこの点が問われていた。Teppeiさんも明確な解決策があるとはしておらず、イベントやメンテナーの伴走を通じて、AIも使いながら貢献を学ぶ機会などを候補として挙げていた。 メンテナーを守るための制限と、新しく参加する人の機会。その両方を考える必要がある。 たとえば、いきなり完成したPRを送る前に、問題の再現を確認する。Issueで変更の方針を相談する。小さな調査や説明から関わり、やり取りを通じて信頼を作る。そうした入口なら、実装の量以外の形でも貢献を示せるのではないかと思った。 ただし、伴走にも時間がかかる。入口を残す仕組みを作るなら、その運営をまた少数のメンテナーに背負わせない方法まで考えたい。 まとめ セキュリティツールで多くの問題を検出できた。修正PRを自動で作れた。 そこまでできると、成果が出たように感じやすい。 でも、受け取った人が重複を調べ直し、誤報かどうかを確認し、変更の意図を読み解く必要があるなら、その人の仕事はどれだけ減ったのだろう。 検出結果を渡すなら、どの条件で問題になるのか、何を根拠にそう判断したのかまで伝えたい。修正案なら、変更の理由と検証結果を揃えたい。新しい情報を増やすことと同じくらい、受け手が判断を終えられるようにすることを考える必要がある。 これはツールの機能にも、自分自身の貢献の仕方にも返ってくる問いだと思う。 Teppeiさんは、失われつつあるフィードバックをどう取り戻すかについて、まだ答えはないとしたうえで、新しい仕組みやツールを作る機会にも触れていた。 自分も、AIによって作れるものが増えることを楽しみたい。そのとき、受け取る人が理解できる説明を添えること、使っているOSSへ改善や感謝を返すこと、次の人が参加できる入口を残すことまで、一緒に考えていきたい。 コードを作りやすくなった今、そのコードを支える人と、支えるためのやり取りに、もう少し目を向けたい。 ここまで読んでいただいた方は、当ブログ筆者である佐田淳史のOWS研究会・招待講演もぜひご覧になってください。私の講演では、AIが発展してきたけど今後どうしていく？の一案について話しています。 speakerdeck.com youtube.com
@_buf @yongfook In search. Since march. ghostty#11159
First really severe frustration I've encountered since switching to ghostty about a year ago. @mitchellh Please can we have a fix/opt-out. Opening python files in @zeddotdev is not dangerous. ghostty#13904
Ghostty 里中文插字会吃掉后面一个字，抓到是微信输入法多发了个 Delete 前段时间在 Ghostty 里用中文输入法时发现，光标停在文字中间打中文，后面那个字会一个接一个消失。跟覆盖模式、跟什么切换快捷键都没关系，一直没有找到原因，昨天实在受不了了，专门花了几分钟来试了下，最终发现： 微信输入法的「中文与英文/数字之间自动加空格」补完那个空格之后，又替终端发了一个 Delete ； Ghostty 按物理键码解释这个事件，下发的就是"删掉光标右边一个字符"。 所以只有 Ghostty 掉字，iTerm2 、TextEdit 、Sublime 、Tabby 都正常。 但是在行尾打就不会出事，多打几个空格把位置占出来也不会，可有时候怎么打都没事。为了这个"时好时坏"，我一开始以为是某个快捷键的问题，还到处去找的那个以为的切换键，结果根本没有这么个东西。 后来换输入法一试就清楚了：百度五笔完全正常，微信输入法必现。 两者唯一的差别就是自动加空格。这个空格要生效，终端得把光标周围的文本告诉输入法。kitty 不告诉，所以在 kitty 里这功能一个空格都不加； Ghostty 和 iTerm2 告诉，空格就来了。 猜不出来，我写了个三十行的小工具，在 Ghostty 里裸读 stdin ，把每个字节按十六进制记下来。 复现序列：先打 12345678，左箭头按四次，打 dd，切中文打 在在，最后再打一个 d。 关键的几行： e5 9c a8 20 "在 " 一次提交（自动空格） 20 64 " d" 一次提交（自动空格） 1b 5b 33 7e CSI 3~ ← 32ms 后，我没按 1b 5b 33 7e CSI 3~ ← 27ms 后，我没按 同一次测试里我自己按退格，进来的是裸的 7f，跟 1b 5b 33 7e 不同源。最终缓冲区是 1234dd 在在在 dd678，5 真没了，不是显示问题。 通过 AI 分析，macOS 上 117 号键码是 Delete （前向删除），Ghostty 的键码表把 117 映射到内部 delete ，编码成 CSI 3 波浪号。它判断"你按的哪个键"用的是物理键码，事件里那个 7f 文本不参与。AppKit 的原生文本视图反过来，用 characters 字段查键位绑定，7f 落到 deleteBackward ； Tabby （ Electron ）直接把控制字符丢掉。同一个事件里，只有按物理键码解释的那个会去删右边的字。 Ghostty 这边其实有一道防护 shouldSuppressComposingControlInput，但它只拦"组字中"且"字符小于 0x20"的情况。这次的删除发生在上屏之后、带的是 0x7f，两个条件都不满足，就漏过去了。 日志重放一遍还能看出为什么时好时坏：第一次 Delete 落下时，光标右边正好是上一次提交留下的空格，吃掉的是空格，屏幕上没感觉；第二次右边是 5，就少一个字。所以掉不掉，只看光标右边那个位置是不是空格。那个"多打几个空格留位"的偏方，也就是把要被吃掉的东西提前摆好了。 关掉微信输入法的「中文与英文/数字之间自动加空格」，或者换个没这特性的输入法，就没有这个问题了。 准备去 github 提个 issue ，发现在 10 月 16 号已经有人提过同症状的讨论（微信输入法下光标前移再打中文会覆盖后面的文字），零回复。应该还没有处理了，先给贴个过程证据，希望早上修复，可围观： ghostty#14732 有同样问题的可以回个帖，我把探针脚本贴上来，你自己跑一遍就知道是不是同一个原因。
How to Install Ghostty 1.4 on Linux and macOS (On Ubuntu 24.04, Use Flatpak) Ghostty 1.4 is out, and if you're on Ubuntu 24.04 LTS, apt install ghostty won't get it for you. The release requires GTK 4.18 and libadwaita 1.7, the release notes say outright that 24.04 doesn't meet that, and Ghostty exits at startup if it loads older libraries. The notes offer two ways out: stay on an older Ghostty, or use the Flatpak. That's awkward, because 1.4 is the release that makes the "should I switch terminals?" question worth asking again. It took seven months, 2,889 commits and 172 contributors. The fixes are the kind you notice: scrollback memory down 70–90%, plain ASCII parsing up from 128 MB/s to 725 MB/s, and on Linux, text that is finally sharp at fractional scaling. The Hacker News thread passed 1,000 points. This post covers the changes you'll feel day to day, install and upgrade steps for macOS, Fedora, Arch and Ubuntu (24.04 included), the config lines that break on upgrade, and moving over from iTerm2, Kitty or Alacritty. What's new in Ghostty 1.4 that you'll actually notice I went through the full changelog, and these are the changes that show up in a normal working day. All numbers are the maintainers' own, from the release notes. | Change | Before | 1.4 | |---|---|---| | Default scrollback limit | 10 MB | 50 MB | | Physical memory for off-screen scrollback | uncompressed | 70–90% less (macOS, 64-bit Linux) | | Page memory per new terminal (macOS) | 128 KiB | ~16 KiB | | GPU memory, 20 hidden tabs (macOS) | ~385 MiB | ~18 MiB | | Plain ASCII parsing | 128 MB/s | 725 MB/s | | cat of a 150 MB file (macOS) | 1.5 s | 566 ms | | Resize with large scrollback | baseline | ~6x faster | To me the memory numbers matter more than the throughput ones. Nobody cats 150 MB files all day, but plenty of us have 30 tabs open with a week of build logs in scrollback. The default scrollback limit went up fivefold and the memory bill still went down. The rest of what I'd care about: - A new OpenGL renderer on GTK. It drops GtkGLArea and renders with EGL on its own thread, exporting DMABUF frames with triple buffering. This fixes the blurry text at fractional scales (#1938). If you run a laptop at 125% or 150%, this alone is reason enough to upgrade. - ghostty +ssh is a drop-in ssh wrapper that installs Ghostty's terminfo on the remote host and falls back to TERM=xterm-256color. It deals with the old "unknown terminal type xterm-ghostty" problem on servers you don't control. - Split drag and drop on GTK, controlled by the new drag-handle option (auto, always, never). - Full Kitty graphics support, now with animation and relative placements. The project calls Ghostty the first terminal outside Kitty to do this. - macOS 27 fixes for the tab bar and titlebar. It still runs back to macOS 13, and launch to a window is about 15% faster. The release also fixes ten security advisories. The one that concerns me most is GHSA-4hwh-wx3w-3fqg: paste protection didn't treat carriage returns as line endings, so a pasted command could run without confirmation in programs that don't use bracketed paste. Two of the advisories name 1.3.0 and 1.3.1 as affected, and I couldn't find a 1.3.2 patch release. Neither could hongminhee on Lobsters, who pointed out that getting the fixes means taking the GTK 4.18 bump and the new defaults along with them. That's a fair complaint, and it's why this post opens with Ubuntu 24.04. How to install Ghostty 1.4 on macOS macOS is the only platform with official prebuilt binaries. Get the DMG from ghostty.org or use the community Homebrew cask, which repackages the same DMG: brew install --cask ghostty # already installed? brew upgrade --cask ghostty If you installed from the DMG, the built-in updater handles it. In 1.4, auto-installed updates no longer prompt you to restart. How to install Ghostty 1.4 on Linux (Fedora, Arch, Ubuntu and others) There are no official Linux binaries. Every package below is built by a distro maintainer or a community volunteer, and each one updates on its own schedule. Check the version before you assume you have 1.4: ghostty --version On Fedora, use the community COPR: sudo dnf copr enable scottames/ghostty sudo dnf install ghostty On Arch it's in [extra], which tracks tagged releases: sudo pacman -S ghostty Ubuntu 26.04 and later has Ghostty in the official repos, but the PPA README listed that package as 1.3.0 in May 2026, so check before you trust it. The mkasberg/ghostty-ubuntu PPA is usually ahead: sudo add-apt-repository ppa:mkasberg/ghostty-ubuntu sudo apt update sudo apt install ghostty When I checked, the PPA was still on 1.3.1. Its README lists Ubuntu 24.04 support as "up to Ghostty 1.3.1", so that route tops out at 1.3.1 on 24.04. openSUSE, Gentoo, Void, Alpine, Solus and NixOS use zypper in ghostty, emerge -av ghostty, xbps-install ghostty, apk add ghostty (testing), eopkg install ghostty, and pkgs.ghostty. They're all listed on the official install page. For anything else there's snap install ghostty --classic, or the community AppImage, which runs as ./Ghostty-${VERSION}-${ARCH}.AppImage after a chmod +x. How to run Ghostty 1.4 on Ubuntu 24.04 LTS 1. Flatpak. It's the workaround the release notes name, and Flatpak apps run on their own runtime instead of the system GTK. I'd start here. 2. AppImage or Snap. Neither project says whether it gets around the GTK 4.18 floor, so read the AppImage's troubleshooting doc before you depend on it. 3. Stay on 1.3.1. The release notes list this as the other option, but you keep the advisories that affect 1.3.x. 4. Upgrade to 26.04. That should clear the GTK floor, but you still need a 1.4 package from somewhere, and the repo and PPA versions above lag. Building from source on 24.04 doesn't help either. The release notes say builds against older GTK headers fail at compile time. Building 1.4 from source The build page was missing two things when I wrote this. Ghostty 1.4 needs Zig 0.17, and the build page still lists 0.15.2 for "1.3.x and tip". There's also a new -Dinstalled-exe-path option. Gingeh reported that leaving it out breaks the systemd unit for ~/.local installs: tar -xf ghostty-1.4.0.tar.gz && cd ghostty-1.4.0/ zig build -p $HOME/.local -Doptimize=ReleaseFast \ -Dinstalled-exe-path=$HOME/.local/bin/ghostty Use the tarball from release.files.ghostty.org. GitHub's auto-generated "Source code" archive is missing preprocessed files. Upgrading from 1.3: config lines that will bite you Read this before you upgrade, because two of the default changes are going to annoy people. # macOS: copy-on-select now defaults to none (was true), so middle-click # paste of the selection stops working. Restore 1.3 behavior with primary. # An explicit "true" now copies to the system clipboard instead. copy-on-select = primary # copy-on-select = clipboard now copies ONLY to the system clipboard. # For the old behavior, use: # copy-on-select = both # scrollback-limit was renamed (old name still works via a compat layer): scrollback-limit-bytes = 50000000 # macOS: cmd+up/down went back to jump_to_prompt. Want scrolling? keybind = cmd+arrow_up=scroll_to_top keybind = cmd+arrow_down=scroll_to_bottom On GTK, ctrl+shift+page_up/page_down now run move_tab, and jump_to_prompt moved to ctrl+shift+arrow_up/down. If a TUI you use needs those keys, unbind them. Run ghostty +show-config after upgrading to see what's actually in effect. The new +explain-config documents any option from the command line. Migrating from iTerm2, Kitty or Alacritty The config file lives at ~/.config/ghostty/config.ghostty on both platforms. On macOS, ~/Library/Application Support/com.mitchellh.ghostty/config.ghostty also loads, after the XDG file, so it wins on conflicts. Reload with cmd+shift+, on macOS or ctrl+shift+, on Linux. | What | Kitty (kitty.conf) | Alacritty (alacritty.toml) | Ghostty | |---|---|---|---| | Font | font_family JetBrains Mono | [font.normal] family = "JetBrains Mono" | font-family = JetBrains Mono | | Size | font_size 13.0 | [font] size = 13.0 | font-size = 13 | | Opacity | background_opacity 0.9 | [window] opacity = 0.9 | background-opacity = 0.9 | | Padding | window_padding_width 8 | [window.padding] x = 8 | window-padding-x = 8 | | Key | map ctrl+shift+t new_tab | [[keyboard.bindings]] | keybind = ctrl+shift+t=new_tab | Coming from iTerm2, there's no import, and iTerm2's settings live in a plist, so you'll be retyping. Set macos-option-as-alt = true if you used Option as Meta, and try Ghostty's quick terminal as a stand-in for the hotkey window. If you rely on tmux -CC integration, keep iTerm2 installed. Commenters in the HN thread who want it say Ghostty doesn't have tmux control mode yet. For Kitty users, the gap that came up on HN is hints mode. One commenter called it "the one feature keeping me from switching." Ghostty doesn't have an equivalent upstream yet, so if you live in hints mode, that may decide it for you. From Alacritty, you gain tabs and splits without needing tmux. You keep a plain-text config, though it isn't TOML. So, is it time to switch? On macOS, I'd say yes. iTerm2 does more, but Ghostty is the faster native app, and 1.4 addresses the memory bloat from lots of tabs that used to be a fair criticism. On Linux it depends on your distro more than on Ghostty. Fedora and Arch ship a new enough GTK, so the upgrade is clean once the packages move: when I checked, Arch had 1.4.0 in extra-testing and the scottames COPR was still on 1.3.1. Ubuntu 24.04 users get a Flatpak or a security backlog. The project runs a six-month release cycle with 1.5 planned for March 2027, and there's been no 1.3.x patch release for the advisories. I'd like to see that change. Ghostty, Kitty, WezTerm or iTerm2: what's your daily terminal, and what would actually make you switch? And if you're running 1.4 on 24.04 through the Flatpak, AppImage or Snap, tell me which one worked. Sources - Ghostty 1.4.0 release notes - Ghostty install docs (binaries) - Ghostty build docs - Ghostty config docs - mkasberg/ghostty-ubuntu - pkgforge-dev/ghostty-appimage - Hacker News discussion - Lobsters discussion
终端历史一多就吃内存，翻旧输出还卡？ ghostty 是 GPU 加速原生终端：1.4 版历史压缩省内存，纯文本解析快 5.7 倍，默认历史上限也从 10MB 提到了 50MB。 对终端常驻几十个窗口的人来说，历史压缩比加内存条实在。 你会先拿它换掉哪个终端？ #终端 #开源 @grok ghostty-org/ghostty
I have a fix in my fork: github.com/ghostty-org/ghostty/commit/95c7fc32280… Inspect + build yourself
Ghostty 1.4.0 completa el protocolo Kitty y parcha 10 fallos de seguridad Ghostty 1.4.0 ya deja animar imágenes Kitty completas, algo que ningún otro terminal fuera de Kitty había logrado hasta hoy. La versión, publicada el 27 de octubre de 2026 por el equipo de Mitchell Hashimoto, suma siete meses de trabajo, 172 colaboradores y 2.889 commits, además de diez correcciones de seguridad. TL;DR - Ghostty 1.4.0, publicado el 27 de octubre de 2026, completa el protocolo de gráficos Kitty con animación.- El emulador es el primer terminal fuera de Kitty en soportar placements relativos de imágenes.- La versión corrige 10 avisos de seguridad, incluidos fallos en el pegado y en el modo de control de tmux.- macOS 27 (Golden Gate) ya funciona sin los defectos visuales que tenía la beta 1.3.1.- Siete meses de desarrollo y 172 colaboradores producen 2.889 commits en este ciclo. Qué es Ghostty Ghostty es un emulador de terminal de código abierto escrito en Zig, creado por Mitchell Hashimoto, cofundador de HashiCorp, y lanzado públicamente en 2024. Renderiza con la GPU del sistema y usa los widgets nativos de cada plataforma en vez de Electron. La versión más reciente, Ghostty 1.4.0, añade el protocolo de gráficos Kitty completo. El proyecto gana terreno frente a alternativas como iTerm2, Windows Terminal o Alacritty gracias a su renderizado por GPU y a funciones pensadas para terminales modernas: integración con shells vía SSH, soporte de temas Nerd Font y, desde esta versión, un protocolo de gráficos completo. Ghostty corre en Linux y macOS, y se instala mediante gestores de paquetes nativos como Homebrew, pacman o los repositorios de cada distribución. Qué pasó con Ghostty 1.4.0 El equipo publicó la nueva release de Ghostty el 27 de octubre de 2026, tras siete meses de trabajo con 172 colaboradores y 2.889 commits. La lista de cambios cubre tres frentes: soporte para macOS 27 (nombre interno Golden Gate), el cierre total del protocolo de gráficos Kitty y diez correcciones de seguridad. En macOS 27, las pestañas en la barra de título (con macos-titlebar-style = tabs) vuelven a alinearse correctamente, la barra de pestañas nativa ya no se dibuja como una franja gris sólida sobre el tema del usuario, y macos-titlebar-style = hidden deja de tapar las primeras líneas de la terminal cuando el sistema tiene activado Reducir transparencia. El ícono de la aplicación perdió también un borde delgado que arrastraba desde versiones anteriores. El terminal escrito en Zig sigue siendo compatible con versiones anteriores, desde macOS 13 (Ventura) en adelante. Más allá de los titulares, las notas detallan mejoras de integración con SSH (el terminal reenvía mejor variables de entorno y configuración de temas al conectarse a un servidor remoto) y una reducción general del uso de memoria en sesiones largas con muchas pestañas abiertas. El equipo también resolvió decenas de reportes menores de renderizado acumulados desde la versión 1.3.1. El ciclo sumó 2.889 commits de 172 colaboradores en siete meses de desarrollo. Contexto e historia del proyecto Mitchell Hashimoto, conocido por fundar HashiCorp (creador de Terraform y Vagrant), presentó Ghostty en público en 2024 tras años de desarrollo privado. El objetivo declarado fue construir una terminal rápida, multiplataforma y con soporte nativo de GPU, sin depender de frameworks como Electron. Desde entonces el proyecto pasó por las versiones 1.0 a 1.3.1, sumando funciones como integración con tmux, mejoras de SSH y soporte parcial del protocolo de gráficos de Kitty. La elección de Zig no es casual: el lenguaje compila a binarios pequeños, no depende de un recolector de basura y facilita el control fino de memoria que un emulador de terminal necesita para dibujar miles de celdas de texto por segundo sin saturar la GPU. Esa base técnica es la que permitió, en esta release, bajar el consumo de memoria sin sacrificar funciones. Ese soporte parcial del protocolo de gráficos generó fricción. Ghostty 1.3.0 y 1.3.1 quedaron expuestos a un fallo (GHSA-hcr9-7hcr-mjm8) que permitía cerrar todas las ventanas abiertas con solo mostrar texto malicioso en modo de control de tmux, sin que tmux estuviera siquiera instalado. La versión 1.4.0 corrige ese fallo y uno relacionado con paneles de tamaño cero (GHSA-hp9c-qp4q-cpw3), ambos heredados de esas dos versiones. Detalles técnicos: cómo funciona el protocolo Kitty completo El protocolo de gráficos de Kitty permite que un programa de terminal transmita datos de imagen directamente al emulador mediante secuencias de escape APC, en vez de depender del servidor gráfico del sistema. El programa envía la imagen en fragmentos codificados en base64, el terminal los decodifica, compone el resultado sobre la cuadrícula de texto y lo muestra en la posición indicada. Hasta la versión 1.3.1, Ghostty soportaba la transmisión de imágenes estáticas pero no la animación ni las posiciones relativas. La animación añade un paso más: el programa transmite varios cuadros con metadatos de temporización y composición, y el terminal se encarga de reproducirlos en orden, calcular cuándo pausar la animación si la pestaña pierde el foco, y liberar la memoria de los cuadros que ya no se necesitan. Las posiciones relativas permiten anclar una imagen «hija» a la colocación de otra imagen «padre»: si el programa mueve la imagen padre, la hija se mueve con ella sin que el programa tenga que recalcular coordenadas en cada fotograma. sequenceDiagram participant P as Programa participant T as Ghostty P->>T: transmite cuadro de imagen (APC) T-->>P: confirma recepción Note over P,T: se repite por cada cuadro de la animación P->>T: indica orden de reproducción T-->>P: reproduce y pausa si la pestaña pierde foco El equipo también hizo una pasada de conformidad completa contra la especificación y contra el propio Kitty, corrigiendo decenas de diferencias de comportamiento. Por ejemplo, ahora las imágenes se desplazan junto con el texto dentro de regiones de scroll, y retransmitir un ID de imagen reemplaza la imagen anterior en lugar de duplicarla. En la práctica, las posiciones relativas sirven para programas que dibujan gráficos compuestos: un visor de imágenes puede mostrar una miniatura flotante sobre la imagen principal, o una herramienta de monitoreo puede superponer un ícono de estado sobre un gráfico más grande, todo sin recalcular coordenadas absolutas en cada fotograma. El cambio se nota con cualquier programa que use el protocolo. Por ejemplo, mostrar un GIF animado con kitten icat: kitten icat logo-animado.gif Antes de la versión 1.4.0, Ghostty mostraba solo el primer cuadro del GIF. Con esta release, el GIF se reproduce completo y se pausa automáticamente si cambiás de pestaña. Ghostty es el primer terminal fuera de Kitty con el protocolo de gráficos completo, según sus notas de versión. Impacto y seguridad: diez fallos corregidos Más allá de las imágenes animadas, la versión 1.4.0 del proyecto cierra diez avisos de seguridad. La mayoría requiere interacción del usuario (pegar texto, hacer cmd-click en un enlace, arrastrar y soltar o confirmar un diálogo): no son fallos explotables de forma remota y silenciosa. Entre los más relevantes, un error en la protección de pegado que no trataba los retornos de carro como fin de línea permitía ejecutar un comando sin confirmación en programas que no usan «bracketed paste» (GHSA-4hwh-wx3w-3fqg). También se corrigieron comandos maliciosos del protocolo de gráficos que podían colgar el programa, forzar asignaciones de memoria enormes o, en casos limitados, leer o borrar archivos fuera de los directorios temporales permitidos (GHSA-mhff-mv4q-fp63). AvisoPlataformaCómo se activaImpactoGHSA-4hwh-wx3w-3fqgTodasPegar texto con retornos de carroEjecuta un comando sin confirmaciónGHSA-mhff-mv4q-fp63TodasMostrar un comando de gráficos maliciosoCuelgue, asignación masiva de memoria o lectura/borrado de archivos limitadoGHSA-hcr9-7hcr-mjm81.3.0 y 1.3.1Mostrar salida en modo de control de tmuxCierra todas las ventanasGHSA-cw69-wm67-5pv8macOSCmd-click en un enlace OSC 8 manipuladoAbre archivos locales o esquemas de URL inseguros El resto de los avisos corregidos incluye un error que corrompía memoria al limpiar la pantalla hacia el scrollback con un límite de buffer configurado en cero (GHSA-w9q4-5jvv-mcv4), y uno que permitía que el nombre de un directorio clonado desde un repositorio no confiable disparara secuencias de escape arbitrarias a través de la integración con zsh o bash, por ejemplo para reemplazar el contenido del portapapeles (GHSA-2r63-vmw6-3m3c). En macOS, abrir un archivo cuyo nombre contiene caracteres de control podía ejecutar un comando distinto al que mostraba el diálogo de confirmación (GHSA-mxqx-236q-wrv7). Un detalle curioso: el mantenedor principal pidió números CVE para estos avisos semanas antes del lanzamiento, pero GitHub todavía no los había asignado al momento de publicar las notas. Es un recordatorio de que el identificador CVE y el aviso de seguridad real no siempre llegan al mismo tiempo. > 📌 Nota: ninguno de los diez avisos de Ghostty 1.4.0 tiene todavía un número CVE formal asignado; el proyecto solo publicó los identificadores GHSA de GitHub. Qué sigue para el emulador de terminal Ghostty El proyecto no publicó un calendario fijo para la próxima versión, pero el patrón de los últimos ciclos (de 1.3.0 a 1.4.0 pasaron siete meses) sugiere que la 1.5 no llegaría antes de mediados de 2027. Es de esperar que las correcciones de seguridad reciban números CVE retroactivos una vez GitHub los asigne, y que el equipo siga puliendo la integración con SSH que esta release ya mejoró. El salto de contribuciones, 172 personas distintas en un solo ciclo, también es un dato relevante para un proyecto que recién cumplió dos años desde su lanzamiento público: sugiere que la comunidad alrededor del terminal escrito en Zig sigue creciendo en vez de depender solo de su autor original. Una limitación que se mantiene: Ghostty no tiene soporte nativo para Windows, algo que lo deja fuera de las opciones para equipos que trabajan exclusivamente en ese sistema. Para esos casos, alternativas como Windows Terminal o WezTerm siguen siendo la opción más directa. 📖 Resumen en Telegram: Ver resumen Probalo vos: si ya usás Ghostty, actualizá con brew upgrade ghostty en macOS o con el paquete de tu distribución en Linux, y corré kitten icat sobre un GIF animado para ver el protocolo de gráficos completo en acción. Preguntas frecuentes ¿Qué es el protocolo de gráficos de Kitty que ahora soporta Ghostty por completo? Es un sistema de secuencias de escape que permite a un programa de terminal transmitir y animar imágenes directamente, sin pasar por el servidor gráfico del sistema. Ghostty 1.4.0 es el primer terminal fuera de Kitty en implementarlo al 100%, incluida la animación. ¿Ghostty es gratuito y de código abierto? Sí. El emulador de terminal se distribuye bajo una licencia de código abierto y su código fuente está disponible en GitHub, igual que el historial completo de cambios de cada versión. ¿Qué versiones de macOS soporta la nueva release de Ghostty? Desde macOS 13 (Ventura) en adelante, incluido el recién llegado macOS 27 (Golden Gate), con correcciones específicas de compatibilidad visual para este último. ¿Los fallos de seguridad corregidos en Ghostty requieren actualizar de inmediato? La mayoría exige que la víctima interactúe (pegar texto, hacer clic o confirmar un diálogo), así que el riesgo no es de ejecución remota silenciosa, pero sigue siendo recomendable actualizar cuanto antes porque varios avisos afectan a usuarios sin que lo noten, como al clonar un repositorio con un nombre de directorio manipulado. ¿Qué lenguaje de programación usa el terminal escrito en Zig? Ghostty está escrito en Zig, un lenguaje de bajo nivel pensado para rendimiento y control de memoria sin un recolector de basura, lo que explica parte de las mejoras de memoria que trae esta versión. Referencias - ghostty.org: notas de la versión 1.4.0 con el changelog completo y los avisos de seguridad.- GitHub: repositorio oficial del código fuente de Ghostty.- Kitty graphics protocol: especificación oficial del protocolo de gráficos que Ghostty ahora implementa por completo.- GHSA-4hwh-wx3w-3fqg: aviso de seguridad sobre la protección de pegado y los retornos de carro. 📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
I actually fixed one cause of this, which is released in 1.4.0. ghostty#12714 The only other cause I've encountered is if a secure input (password) field is focused, since macOS won't give apps global keyboard events for obvious reasons. If you focus a normal text input, it should start working again. I have noticed where macOS doesn't properly release its reference to a Secure Input properly. I've documented how to determine if this is the cause here: ghostty#11883
Ghostty + tmux 쓰는 분들에게. 어제 나온 Ghostty 1.4에서 tmux extended-keys 켜두면 한글 입력 상태에서 Ctrl-U 같은 키가 안 먹습니다 Ctrl-ㅕ로 받거든요. 당장은 extended-keys off 말곤 방법이 없고, 이 PR 이후 생긴 문제입니다. ghostty#14144