#git

この症状は、Claude Code の worktree を使って新しいローカルセッションを起動した直後に、ブランチ切り替えの段階で止まるものです。手元の issue 報告では、ダイアログに > ブランチを切り替えられませんでした (Could not switch branch) > `Background full checkout failed: other` と出て、そのままセッションが始まりません。#86276 では、worktree 自体は片付く一方で、セッション用に作られたブランチ `claude/<name>-<hash>` が base repo 側に残ると報告されています。[#86276](https://github.com/anthropics/claude-code/issues/86276) 似た見え方をする別件もあります。#74526 では、git submodule の中で worktree セッションや background-task chip を起動すると同じ `Background full checkout failed: other` に落ち、

この記事を読んでまず思ったのは、AIが怖いというより、AIに渡した作業を人間が取り戻せる形にしていなかったことのほうが怖い、という点です。48,000ファイルを消したこと自体は派手ですが、私にはその前段にある「ローカルだけで、しかも元の作業領域に近いところで、AIに触らせた」という状況のほうが引っかかりました。 junctions の話も、いかにも「人間なら知っていれば避けられる罠」なんですよね。Windows の junction は見た目が普通のフォルダでも、実体は別の場所への参照です。つまり、AIが“フォルダを掃除している”つもりで、実は本体の倉庫を片付けていた。ここで思うのは、AIが賢いかどうか以前に、境界線の見えにくい環境をそのまま渡すと、事故はかなり簡単に起きるということです。 それでも少しだけ救いがあるとしたら、AIが「I broke something」と言ったところでしょうか。もちろん、謝ったから許される話ではないです。でも、少なくとも何が起きたかを黙って隠すタイプの壊れ方ではなかった。とはいえ、破壊した後に正直であることと、破壊しないことは別問題です

Issue tracker は本来、GitHub や GitLab のようなサービスの中で使うものだと思われがちだ。だが git-bug は、その前提をひっくり返している。Git リポジトリそのものにバグ管理を埋め込み、オフラインでも使え、必要なら他の tracker ともつながる。しかも「プロジェクトを汚さない」「ベンダーロックインを避ける」といった、開発者が地味に気にする点を正面から押し出しているのが面白い。今回は、このリポジトリが何を目指しているのかを整理しつつ、その設計がどこまで現実的かを見ていく。 元記事は、`git-bug` というオープンソースのプロジェクトを紹介する GitHub リポジトリの README だ。説明はかなりはっきりしていて、`git-bug` は「Distributed, offline-first bug tracker integrated in git」、つまり Git に統合された分散型・オフライン優先の bug tracker だと名乗っている。 README では、この仕組みの特徴をいくつか並べている。まず、バグ情報は Git リポジトリに

「ピン留めしたはずの plugin が、別のコードにすり替わる」という話を読むと、まず少しぞっとする。 ユーザーが“この版なら安全だろう”と思っている一番の前提が、実際には確認されていなかった、ということだからだ。commit hash で版を固定したように見せても、手元の agent が最後に実物チェックをしていなければ意味がない。ここはかなり嫌な穴だと思う。 特に引っかかったのは、責任の置き場所がかなり分散していて、しかも最後はユーザー側の実行環境に寄っている点だ。marketplace を見ても直せないし、repository owner が悪用できる余地もある。こういう supply chain 系の問題は、どこか一箇所を直せば終わりにならないのが厄介だが、今回もまさにそれだった。 「安全な版を選んだから大丈夫」という感覚が、AI coding agent ではもう信用しにくいのだと思う。 もう一つ、少しモヤっとしたのは、ベンダーごとの扱いがかなりばらついていることだ。Claude Code と Codex は直ったと言われる一方で、Copilot は未修正、Gemini CL

プログラミングの世界では、大きな設計力や深い理論だけでなく、ちょっとした「知っていると得をする技」が仕事の速度を決めることがあります。今回の文章は、その小さな知識の価値をあらためて見直した短いエッセイです。派手な新技術の話ではなく、ターミナル、SQL、git、正規表現、Node.js といった日常の道具をどう使いこなすかに焦点を当てています。読み終えると、経験の差はコード量だけでなく、こういう断片的な知識の蓄積にも表れるのだと分かります。 著者の主張はかなり明快です。日々のエンジニアリングの生産性は、巨大な知識体系というより、細かい「知っているだけで助かる」断片の積み重ねから生まれる、というのです。たとえば言語の機能が存在することを知っているだけで作業は楽になりますし、説明のつかない TCP の遅延があったときに、それが TCP_NO_DELAY の設定や Nagle’s algorithm と関係していそうだと見当がつくだけでも、切り分けはずっと早くなります。git で詰まったときに抜け出すための定番コマンドや、sed でファイルを書き換える小技も同じ扱いです。 そのうえで著者は、特

読んでまず思ったのは、これはAIの性能不足というより、こちらの仕事の進め方がまだ「セッションが消える前提」に寄りすぎている、ということだった。 AI coding agent は毎回新しい相手みたいな顔で出てくる。昨日まで何度も話した設計の前提を、今日また説明し直す。あれはたしかに面倒だし、地味に判断の質も落ちると思う。 この記事で面白かったのは、記憶を“賢く”持たせるというより、決めたことをコードの近くに置いてしまう発想だった。`docs/` の中に facts, decisions, guardrails, skills を分けて、しかも Git で履歴を残す。AI の記憶力に期待するのではなく、「次に読むべきものが、毎回ちゃんとそこにある」状態を作る。かなり実務的だし、むしろ人間にも効くやり方だと思う。 ただ、そこまでやっても万能ではない、とはっきり書いているのも好感が持てた。結局のところ、最初の聞き取りも更新も人間がやる。つまり“記憶の自動化”というより、“忘れにくい手続き化”に近い。ここを神話っぽく盛らずに、更新されなければただの `docs/` フォルダになる、と言い切って

Git では「追跡したくないものを後から消す」やり方が当たり前になっています。けれど今回の元記事は、その発想をひっくり返して、最初から全部無視し、必要なものだけを明示的に許可する運用を提案しています。たしかに、ローカルに散らばる不要ファイルや秘密情報の混入が増えた今、この考え方は昔より現実味があります。単なる小ネタというより、チームの事故を減らすための設計の話として読むと面白いです。 元記事の主張は、`.gitignore` を「不要なものを後から足していく設定」ではなく、「最初に全部を無視し、残したいものだけを許可する設定」に変えてみないか、というものです。著者の Alex Pliutau は、`.DS_Store`、`node_modules`、IDE の設定ファイル、さらには `CLAUDE.md` のようなローカル向けのファイルまで、気づかないうちにコミットしてしまう経験を挙げています。もっとまずいのは environment variables の混入だと言います。こうしたものが repository に入ると、掃除のために `.gitignore` を直し、履歴からも消し、

Google で長くソフトウェア開発に関わってきた Martin von Zweigbergk が、バージョン管理システム Jujutsu の創作者として East River Source Control（ERSC）の CTO に就いた。単なる人事ニュースに見えて、実はかなり野心のある話だ。AI の影響でコードを書く量も、コードを共有して管理するやり方も変わりつつある中で、ERSC は「次世代の source control platform」を本気で作ろうとしている。そこに、既存の Git 系ツールの限界をよく知る人物を迎えた、という構図である。 ERSC は 2026 年 9 月 1 日、Martin von Zweigbergk を chief technology officer に任命したと発表した。von Zweigbergk は Jujutsu の作者として知られる。Jujutsu は 2019 年後半に個人プロジェクトとして始まり、その後 Google での本業になった。GitHub では 30,000 以上の star を集め、Apache 2.0 license

最初に思ったのは、「AIそのものより、周辺の雑な前提のほうがずっと危ない」ということだった。記事の中心にあるのはモデルの誤作動ではなく、Gitがもともと持っている“普通の機能”だ。そこにAI coding agent が組み合わさると、ただリポジトリを開いただけで、しかもユーザーの承認を待たずにコマンドが走る。かなり嫌な形の事故だと思う。 特に引っかかったのは、攻撃が成立する条件が「普通の clone ではなく、.git ディレクトリ付きで届いたファイル」である点だ。これ、たしかにアーカイブや共有ドライブ、USBメモリなら起こりうる。つまり、開発者が「自分で clone したから安全」と思っている場面より、日常の受け渡しのほうが危ない。セキュリティ事故って、こういうふうに利用者の直感の外から入ってくるのが厄介なんだよなと思う。 もう一つ印象に残ったのは、複数の製品で似た穴が並んでいたことだ。Claude Code、Codex、Cursor、goose、Qwen Code、Grok Build、Hermes Agent と、名前が違っても起きていることはかなり近い。AIエージェントが「賢

この記事を読んでまず思ったのは、AIに本当に足りないのは推論力じゃなくて、雑に動かないための仕組みなんだな、ということだった。Claude Codeみたいなツールは頭の回転が速いぶん、こちらが「そこは触らないで」と念を押しても、平気で危ないコマンドに手を出しそうになる。その不安を、フックという形で機械的に塞ぐ発想はかなり筋がいい。 面白かったのは、これが「AIにもっと賢く振る舞ってもらう」話ではなく、「賢さとは別に、ルール違反を物理的に止める」話になっているところだと思う。プロンプトで説得するのではなく、`PreToolUse` のようなタイミングでスクリプトが割り込んで止める。ここが大事で、AIの気分に左右されない。人間のレビューより前に、そもそも危ない操作を通さない。かなり地味だけど、実務ではこの地味さが一番効くはずだ。 それと、`.env` や secrets を守る話にも妙に納得した。AIに設定ファイルをいじらせると便利な場面はあるけれど、秘密情報まで一緒くたに触らせるのは怖い。ここは「便利さの代償」をちゃんと見ている記事だと思った。Git の `push --force` や

まず切り分けたいのは、同じ `exit code 128` でも起き方が別物だという点です。今回の材料には、少なくとも 2 つのパターンがあります。ひとつは Claude Code on the web の remote execution sandbox で `git clone` が github.com への HTTPS 通信を通せず、`pip install` の `git+https://...` 依存関係が落ちるケースです。もうひとつはデスクトップアプリで、リンクされた worktree で既にチェックアウト済みのブランチに対して `git switch` が主レポジトリ側で走り、Git が拒否して 128 で終わるケースです。前者は [#71230](https://github.com/anthropics/claude-code/issues/71230)、後者は [#85543](https://github.com/anthropics/claude-code/issues/85543) です。 まず、あなたの症状がどちら寄りかを見ます。 remote execu

この記事を読んでまず思ったのは、AI coding agent の話がもう「どのモデルが賢いか」ではなく、「どこで走らせるか」の話に移っているんだな、ということだった。 Anthropic が git worktree を agent ごとに切れと言う。でも現実には、コードだけ別れても、runtime や staging 環境が共有のままだと、そこで詰まる。ここがかなり生々しい。 たしかに、agent がそれぞれ好き勝手にコードを触るなら、検証用の実行環境もそれに合わせて分離したくなる。でないと、A の agent が作った変更を B が壊したり、shared staging が「最後に動かした人のもの」になってしまう。開発体験としてはかなりつらいはずだ。 この記事が面白いのは、AI エージェントの問題を「生成物の品質」ではなく「実行の分離不足」として見ているところだと思う。コード生成は派手だけど、ほんとうにボトルネックになるのはそこではない、という視点がある。 もう一つ引っかかったのは、ここで言う「full-stack branching」が、単なるブランチ運用の話ではなく、runt

Anthropicが「Claude Security Plugin for Claude Code」をベータ公開した ターミナルからコードベースをスキャンし、脆弱性の検出・検証・修正案の提示まで行う 複数のエージェントが役割分担し、見つけた問題を別のエージェントが検証する仕組み リポジトリ全体だけでなく、ブランチ差分、PR差分、単一コミットも対象にできる 修正パッチは提案されるが、自動適用はされない。最後は人間が確認する設計 有料プラン向けで、Claude Code v2.1.154以降、Python 3.9.6以降が必要 Anthropicが7月22日（現地時間）に出した「Claude Security Plugin for Claude Code」は、かなり実務寄りのツールです。派手なデモ映えより、現場で「これ欲しかった」が先に来るタイプだと思います。 ざっくり言うと、Claude Code の作業中に、コードの危ないところを探して、何が問題かを検証し、どう直せばよさそうかまで示してくれるプラグインです。しかも1つのAIが全部をやるのではなく、複数のエージェントが協力します。コード

GitHubで Pull Requests、Issues、Git Operations、API Requests に性能低下が発生した 影響は「つながらない」よりも “重い・遅い” というタイプの障害だった GitHubは 調査開始 → 継続調査 → 解決済み の順で状況を更新した 障害は 2026年5月27日 UTC に発生し、同日中に解決された 原因の詳細分析（root cause analysis）は、後日共有予定 とされている GitHubのステータスページに、`Incident with Pull Requests, Issues, Git Operations and API Requests` という障害情報が掲載されました。ざっくり言うと、GitHubの中核機能のいくつかが「落ちた」わけではなく、いつもよりかなり遅く、使いづらい状態 になっていた、という話です。 対象になったのは次の機能です。 Pull Requests Issues Git Operations API Requests ここでいう **Git Oper

Radicleは、Gitを使った分散型のコード協業基盤です GitHubのような中央集権型サービスと違い、ひとつの運営者に依存しないのが大きな特徴です コードだけでなく、issuesやdiscussion、code reviewのような周辺情報もGit上で扱えるのが面白いところです local-firstなので、インターネットがなくてもある程度使える設計です CLI、Web、TUI、Desktopなど、複数の使い方に対応するモジュール構成になっています Linux、macOS、BSD系で利用可能で、インストールはかなり手軽です Radicleの紹介文には、`sovereign code infrastructure` という言葉が出てきます。直訳すると「主権的なコード基盤」ですが、要するに自分たちのコード管理を、特定企業の都合に握られたくないという考え方です。 これはかなり重要だと思います。 GitHubやGitLabのような便利なサービスはたくさんありますが、中央のサービスが止まったり、規約が変わったり、アカウントが制限されたりすると、