ctimeは作成日時ではなく変更日時のようです。実際にmacOS上で動作確認をするとupdatedAtと同じソートになりました。以下、Claude Codeのコメントです。

VSCode の FileStat の仕様を確認すると：

重要: ctime は「作成日時（creation time）」ではありません。POSIX系システムでは「inode変更時刻（change time）」です。ファイルのパーミッション変更などでも更新されます。

そのため、ctime と mtime がほぼ同じ値になるケースが多く、created でソートしても updated と同じ結果になります。

対策案

macOS/Linuxで「真の作成日時（birthtime）」を取得するには、Node.js の fs.stat() を使う必要があります：

  import * as fs from "fs";

  const stat = fs.statSync(filePath);
  console.log(stat.birthtime); // 真の作成日時

ただし、VSCode の workspace.fs.stat() では birthtime は取得できません。

@cm-igarashi-ryosuke
ご確認ありがとうございます。
こちらもmacですが、createdとupdatedで挙動は異なっています。
動作確認時のgifを共有いたします。
そちらではどのように確認をされたでしょうか？

@kiitosu ありがとうございます。共有いただいた画面ではうまく動いていそうですね。

私のローカル環境で pnpm dev して立ち上げて動画を撮りました。

また、各itemのctimeとmtimeをログ出力したのですが、全て同じ値でした。

console.log(`[${item.path}] ctime:${stat.ctime} mtime:${stat.mtime}`);

環境による違いでしょうか（詳細は調べられていないですがご報告まで 🙇 ）

こちらで以下確認すると

console.log(`[${item.path}] ctime:${stat.ctime} mtime:${stat.mtime}`);

ctimeとmtimeの値は異なりますね。
なお、こちらではM1 macで動作確認をしています。
igarashiさんはブラウザで立ち上げてる感じですかね。そうするとctimeがmtimeになってしまうのかもしれません。

nodejsのfsを使おうとしてみたのですが、どうやらブラウザ版のvscodeではnodejsのfsが使えないようでした。(当方フロントエンドに疎く、そのようにgemini,chatgptに言われたという感じです)

となると案としては以下２つのどちらかでしょうか。

1. ローカルアプリ用にctimeを残す。web版のvscodeではctimeとmtimeのソート結果がおなじになる。
2. 動作がおなじになることを優先して、ctimeによるソートは削除する

説明するのも難しいので2がいいですかね。

@kiitosu ありがとうございます。

まず冒頭のClaude Codeのコメントにつきましては、誤りの可能性が高いです。ctime, mtime はLinuxシステムなどでも使われているキーワードで、混同した可能性が高いです。失礼しました 🙇

VSCode拡張として利用した場合は、ctimeとmtimeは異なる値を返すのですね。

リファレンスを少し調べてみたところ、以下のように記述されていました。
ctime は The creation timestamp と記述されていますので、正しそうです。

ctime: number

The creation timestamp in milliseconds elapsed since January 1, 1970 00:00:00 UTC.

mtime: number

The modification timestamp in milliseconds elapsed since January 1, 1970 00:00:00 UTC.

Note: If the file changed, it is important to provide an updated mtime that advanced from the previous value. Otherwise there may be optimizations in place that will not show the updated file contents in an editor for example.

一方、Web拡張につきましては、実行環境が異なり制約があると記述されています。

Web extensions share the same structure as regular extensions, but given the different runtime, don't run with the same code as extensions written for a Node.js runtime. Web extensions still have access to the full VS Code API, but no longer to the Node.js APIs and module loading. Instead, web extensions are restricted by the browser sandbox and therefore have limitations compared to normal extensions.

また、ctime, mtime の具体的な言及はないものの、file system については仮想的な環境であると記述されています。

方針ですが、このプロジェクト自体がWeb拡張向けとして作られているためWeb拡張で動作することを優先したいことと、おそらく最終更新時間の方が利用シーンが多いことを考え、案2（updatedだけを追加）が良いと思いました。

@cm-igarashi-ryosuke
作成日ソートを削除しました！

9e4ac55

@kiitosu すみません、動作確認をしていてもう一点問題に気づきました。

Web拡張環境下では、stat.mtime の初期値は実際のファイルの最終更新日時を示しておらず、すべてのファイルでほぼ同じ値になります。

VSCode上で更新されることでこの値は更新されますが、更新されていないファイルはファイル名順になり、ソートとしては不完全な状態となります。

不自然にならない方法を考えてみたのですがいい方法が思いつかず。アイディアありましたらお願いします 🙇

なるほどー。WEB拡張環境だとなかなか厄介なんですね。私もちょっと難しいのかなと思いました。本PRはcloseするのがいいですかね。

@kiitosu そうですね。技術的な解決、もしくは、UI上の工夫でやりたいことが実現できれば良いのですが。

ちなみに github.dev で 標準のエクスプローラーのソートを更新日時順にする設定があったので試してみたのですが、やはり実際のファイルの更新日時順にはならなかったので、難しいのかもしれません。

ここまでご対応いただいたのに申し訳ないです。