#windows

`Claude Code process exited with code 3` が出ても、すべてが同じ原因とは限りません。少なくとも今回集めた issue では、Windows 側で常駐している Windhawk が関わるケースと、Hyper-V の仮想マシン内で Claude Code のバイナリが落ちるケースが別々に報告されています。 自分の症状がどちらに近いか、先に分けるのがよさそうです。 ターミナルでは動くのにデスクトップアプリ側だけで落ちるなら、[#52386](https://github.com/anthropics/claude-code/issues/52386) の報告とかなり似ています。報告者は「昨日までは動いていたが、今日は毎回 `Claude Code process exited with code 3` になる」「terminal では引き続き動く」と書いています。さらに Windhawk を終了すると直るとも述べています。 一方で、Windows の Cowork 経由で、VM の起動自体は成功するのに Claude Code の binary が始ま

まず、自分のケースかどうかを切り分けます。今回の報告で共通していたのは、Windows 上で Claude Code を使っていること、そして `EEXIST` が出ていることでした。ひとつは worktree の扱いで「git リポジトリではない」と誤判定される話、もうひとつは `~/.claude/session-env/<session-id>` を作るところで `mkdir` が `EEXIST` になる話です。前者は [#40164](https://github.com/anthropics/claude-code/issues/40164)、後者は [#65309](https://github.com/anthropics/claude-code/issues/65309) です。 ただし、筆者の手元で確認できたのは macOS 上の Claude Code 2.1.207 までです。Windows で同じ再現確認はしていません。なので、ここで書けるのは「こういう症状の issue が実際にある」「手元の環境ではこのバージョンとこの導入状態だった」という範囲に限られます

まず自分のケースかどうかを見るなら、今回集めた issue では「ネットワーク越しのボリューム」や「Windows のパス解決」で `EPERM` が出ています。ローカルディスクの単純な読み書きではなく、保存先や対象が少し特殊なときに崩れていました。 たとえば macOS では、SMB マウントされた volume 上のファイルに対して Read/Bash を走らせると `Operation not permitted` が返る報告があります。報告者は mount の所有者で、`smbutil statshares` でも SMB 3.1.1 と暗号化有効を確認していました。それでも `dangerouslyDisableSandbox: true` では止められず、`--add-dir /Volumes/storage` か `permissions.additionalDirectories` を追加する回避策しか見つかっていませんでした。これが [#57540](https://github.com/anthropics/claude-code/issues/57540) です。

「Teamsで通知が届かない・音が鳴らない」というガイドは2025年3月ごろから定番のネタとして各所で書かれてきた。1年以上経った今もう一度読み直してみると、当時のチェックリストは今でも土台としては有効だが、2026年に入ってから起きている不具合は、当時想定されていなかった種類のものだとわかる。 代表格が2つある。ひとつは4月中旬から報告が相次いだ「通知がデスクトップに張り付いたまま消えない」不具合。もうひとつは、Plannerのタスクチャット刷新に伴って意図的に仕様変更された「コメント通知が来なくなった」現象だ。前者はバグ、後者は仕様変更——原因が真逆なのに、ユーザー側からはどちらも「通知がおかしい」としか見えない。本稿ではこの2つを軸に、旧来のチェックリストをどう位置づけ直せばいいかを整理する。 --- 症状が「来ない」のか「消えない」のか「減った」のかで、疑うべき場所が変わる。 | 症状 | まず疑うもの | 対処 | |---|---|---| | バナーも音も一切来ない | 3層構造（後述）のどこかでオフになっている | 下記「3層」を上から順に確認

「昨日まで普通に使えていたClassic Outlookが、右クリックした瞬間に落ちる」「起動してもすぐ強制終了し、次はセーフモードで開く」——2026年6月末から、この手の悲鳴がまた一気に増えた。半年前・1年前に書かれた「Outlookが起動しない完全解決ガイド」的な記事が今また読まれているのは、まさに今、Classic Outlookのクラッシュが立て続けに起きているからだ。 本稿は、2026年前半に発生した複数のクラッシュ事案を発生時期・影響ビルド・原因・修正状況で整理し直し、「自分のケースはどれで、何をすれば直るか」を最短で切り分けられるようにしたものだ。結論から言うと、直近の主犯は更新プログラムの回帰（リグレッション）で、多くは“Officeを最新へ更新するだけ”で直る。設定を9個いじる前に、まずここを見たほうが早い。 > ⚠️ 先に結論: 2026年6月29日ごろから急にClassic Outlookが落ち始めたなら、疑うべきは自分の設定ではなく **Microsoft 365 Apps バージョン2605（Build 20026.20182

For Claude and Claude Code users, this bug report is interesting because it exposes a very real gap between chat-first usage and agent infrastructure on Windows. Even if you never intend to use Cowork or agent mode, the desktop app may still spin up a heavyweight virtualized stack in the background, and that’s the kind of thing developers notice immediately on a constrained machine. A GitHub issue reports that Claude Desktop on Windows spawns a Hyper-V VM on every launch, even for chat-only use.

Microsoftと、Nightmare Eclipse（別名 Chaotic Eclipse）と名乗る研究者の対立が激化している 研究者はこれまでに 6件のWindows 0-day を公開し、うち 3件は実際に攻撃で悪用 されている Microsoftは「正式な手順で報告されていない」と主張し、法的対応を示唆した 研究者側は、Microsoftに連絡を無視され、アカウント削除や報酬なしの扱いを受けたと反発している 次の“公開予告”として 7月14日 が示されており、事態はさらに悪化する可能性がある この騒動は、脆弱性報告のルール作りがいかに難しいかを改めて見せつけている 今回の話は、かなり人間くさいです。 単なる「脆弱性が見つかった」「パッチが出た」という技術ニュースではなく、研究者とMicrosoftの関係が完全にこじれた結果、0-day公開合戦みたいな状態になっている、というのが本質です。 記事によると、Nightmare Eclipse（Chaotic Eclipseとも呼ばれる）は、Windowsの深い知識を持つ一方で、Microsoftに強

Microsoftが、Windowsのゼロデイ脆弱性を投稿したセキュリティ研究者のGitHubアカウントを停止した 研究者側は「Microsoftに人生を台無しにされた」と主張し、今回の対応を「報復的だ」と非難している 研究者はGitLabへ移動し、さらに反撃を続ける構えを見せている ただし、脅迫めいた発言も含まれており、今回の件は単なる“意見の対立”では済まない重い問題になっている Tom's Hardwareが報じたのは、Microsoftとセキュリティ研究者のあいだで起きた、かなり後味の悪い一件です。 対象になったのは、Nightmare-Eclipse、別名 Chaotic Eclipse と呼ばれる研究者です。 この人物は、Windowsのゼロデイ exploit を投稿したことで、MicrosoftのGitHubアカウントを停止されたとされています。 ここでいう ゼロデイ とは、まだ修正されていない脆弱性 のこと。つまり、悪用されると危険なのに、メーカー側の対策がまだ間に合っていない状態です。 そして exploit は、その

この記事は、Excelの共有しているブックを解除する方法を扱っている 解除は［アクセス許可の管理］から行う メールアドレスで共有した相手との共有は、相手を外すことで解除できる URLを送って共有した場合は、そのリンクを無効化する必要がある 共有の仕組みを知っておくと、「もう見せたくない」「共同編集をやめたい」ときに慌てず済む Excelでいう「ブック」は、ざっくり言えば1つのExcelファイルのことです。 それをOneDrive経由で共有すると、他の人と同じファイルを見たり、編集したりできます。 これは便利なんですが、実際に使っていると「共有をやめたい」「この人だけ外したい」「リンクをもう使えなくしたい」という場面、けっこうあります。 個人的には、共有は始めるより終わらせ方のほうが大事だと思います。止め方を知らない共有は、ちょっと怖いですからね。 元記事の結論はかなり明快で、［アクセス許可の管理］で解除する、というものです。 ここでいう「アクセス許可」とは、そのファイルに誰が入れるか、誰が見られるか、編集できるかを管理する

Excelのブック共有は、Excelを開かなくても設定できる 方法は、エクスプローラー上で操作すること 共有したいブックは、OneDriveと同期しているフォルダーに移動して使う 「Excelを起動して、ファイルを開いて……」と考えがちだが、実はもっと手早い 個人的には、こういう地味だけど効く小ワザがいちばんありがたいと思う 今回の元記事は、「Excelで開かないとブックを共有できないの？」という、かなり実用的な疑問に答えたQ&Aです。 結論からいうと、ブックの共有はExcelを開かなくても設定できます。 しかもやり方は意外とシンプルで、エクスプローラー（Windowsでファイルやフォルダーを見たり移動したりする画面）から操作できる、というのがポイントです。 これ、ぱっと見は「え、そんなのでいいの？」と思うかもしれません。 でも実際、ファイル共有や共同編集って、毎回Excelを起動して中から設定するより、ファイルの置き場所と同期状態を整えるほうが本質なんですよね。ここがわかると、Microsoft 365時代のファイル管理がかなり

Microsoftの月例修正「Patch Tuesday」の直後に、Windowsの新しいゼロデイ脆弱性が3件公開された 脆弱性の名前は YellowKey、GreenPlasma、MiniPlasma YellowKeyはBitLockerを物理アクセスだけで突破しうる GreenPlasmaはWindowsの権限をSYSTEMまで引き上げられる可能性がある MiniPlasmaは2020年に修正されたはずの古いCVEが、いまも悪用できるとされている ここ6週間で、研究者 Nightmare Eclipse が公開した脆弱性は合計6件に達した 一部はすでに悪用中、少なくとも1件はCISAのKEVにも入っている Dark Readingが伝えているのは、Windowsの脆弱性公開がまだ終わっていない、というかなり重たい話です。 Microsoftが毎月まとめて行う修正日は「Patch Tuesday」と呼ばれます。簡単に言うと、Windowsの不具合やセキュリティ問題を定期的に直す“月例メンテ日”です。ところが、その直後にまた新しい穴が見つかる。しかも今回は1件ではなく3件。なかなか嫌

Windowsに昔から入っている `MSHTA` が、攻撃者に悪用されている 入口はフィッシングや「無料ソフト」「クラック版」を装った誘導が多い `LOLBIN`（正規ツールの悪用）なので、見た目では不審さが出にくい `Lumma`、`Amatera`、`ClipBanker`、`PurpleFox` などの配布に使われている 対策は「ユーザー教育」だけでなく、「古い機能を止める」技術的対策も重要 最近のサイバー攻撃で、ちょっと皮肉なのがこの話です。 Windowsの“昔ながらの正規機能”が、マルウェア配布の便利な道具になっているんですね。SecurityWeekの記事は、Microsoftの `MSHTA` という古いユーティリティが、静かにマルウェアをばらまく攻撃で急増していると伝えています。 率直に言うと、これはかなり厄介です。 なぜなら `MSHTA` は「怪しい外部ツール」ではなく、Microsoftが署名した正規の機能だからです。セキュリティ製品から見ると、完全に即ブロックしづらい。攻撃者からすると、これほど都合のいい入口はありません。 `MSHTA` は

MicrosoftがPatch Tuesdayで138件の脆弱性を修正 そのうち30件がCriticalで、かなり重めの内容 Windows DNSとNetlogonに、ネットワーク経由でコード実行されうる深刻な欠陥 Secure Boot証明書の更新も重要で、放置すると来月以降に問題が出る可能性 Microsoft自身も、AIを使った脆弱性発見の加速で今後パッチ件数が増えると見ている --- Microsoftがまた大仕事をやっています。今回のPatch Tuesdayでは、なんと138件もの脆弱性に対して修正パッチが公開されました。しかも、そのうち30件がCritical。セキュリティ修正の世界では、これはかなりのボリュームです。 個人的には、ここが一番面白いところだと思います。単に「件数が多い」だけではなく、AIを使った脆弱性発見が加速していて、パッチの規模そのものが膨らみつつある、という流れがはっきり見えてきています。便利さの裏で、守る側の仕事もどんどん増えているわけです。 The Hacker Newsに

匿名の研究者が、Microsoft製品の未修正ゼロデイ脆弱性を2件追加で公開した 1つはBitLocker回避、もう1つは権限昇格につながる問題 BitLocker回避が本当なら、盗難PCが“ただの紛失”では済まなくなる可能性がある 権限昇格のほうは、現時点では完全なPoCではないが、悪用される土台は示されている 研究者は今年だけで複数のゼロデイを公開しており、Microsoftへの報復的な流れが続いているように見える The Registerによると、Microsoftの脆弱性を立て続けに公開している匿名の研究者が、また2件のゼロデイ情報を出しました。 今回の名前は YellowKey と GreenPlasma。前者は BitLocker bypass、後者は privilege escalation（権限昇格）です。 ざっくり言うと、BitLocker bypassは「暗号化されたはずのPCの守りをすり抜ける」話、権限昇格は「一般ユーザーとして入ったあと、管理者権限やSYSTEM権限まで上がる」話です

Microsoftが、AIエージェントを束ねて脆弱性を探す新基盤「MDASH」を公開した MDASHは Multi-Model Agentic Scanning Harness の略で、100個以上のAIエージェントを連携させて動かす すでにWindows関連で 16件の新たな脆弱性 を発見し、そのうち 4件は重大（critical） 2件は リモートコード実行（RCE） につながる深刻な問題で、May updateで修正された テストでは false positive（誤検知）ゼロ をうたっており、かなり印象がいい ただし、これは「AIが全部解決する」話ではなく、AIをどう運用するか が本質だと感じる --- Microsoftが、AIを使ったセキュリティ基盤「MDASH」を発表しました。 名前だけ聞くと「またAIっぽい新製品かな？」と思うかもしれませんが、今回はわりと本気です。というのも、MDASHはすでに Windowsの新しい脆弱性を16件発見 していて、その中には 4件の重大なもの が含まれているからです。 しか