anthropics / anthropics/claude-code
[BUG] Claude Code writes `.in_use/<pid>` and `.orphaned_at` into the versioned plugin cache after install, so the installed tree no longer matches what was pinned
- 主要言語
- Python
- スター
- 145k
- フォーク
- 23.1k
- PR マージ指標
- PR 指標を取得中
説明
### Preflight Checklist
- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
### What's Wrong?
After a plugin is installed and its digest checked against the marketplace entry, Claude Code writes its own bookkeeping files into the same versioned plugin directory under `~/.claude/plugins/cache////`:
- `.in_use/`, one file per running session, containing {"pid":42644,"procStartFt":"134335282263740158"}
- `.orphaned_at`, a Unix-millisecond timestamp (e.g. 1788889068596), written to a version directory once a newer version is installed
Both are stamped later than every published file and neither came from the publisher. The tree on disk therefore stops matching the tree that was pinned at install.
Anything that re-verifies the installed plugin against a complete file list (a tree digest, a signed manifest, an org-level integrity check) reports these as an unlisted addition, which is a correct finding about the directory and a wrong finding about the plugin. There is no published list of which paths inside a plugin directory belong to the host, so every verifier discovers them one at a time by hitting the false alarm.
This also means the install-time sha/sha256 pin cannot be re-checked against the cache by anyone, including Claude Code itself, once the host has written into the tree.
Disclosure: I build PromptSign, a signing tool for these artifacts, which is how I hit this. The request stands independent of it.
### What Should Happen?
The versioned plugin directory should contain only what the publisher shipped, so that it can be re-verified against the install-time pin (or a publisher signature) at any later time and still match.
Either of these would do:
1. Write host bookkeeping outside the versioned tree. For example `~/.claude/plugins/cache///.state//`, or a sibling of the version directory, so the pinned tree is never mutated after the install-time check.
2. If the files have to stay inside the versioned directory, document the complete set of host-owned paths (today: `.in_use/` and `.orphaned_at`) in the plugin docs and treat that list as a stable contract, so an integrity check can exclude exactly those paths and nothing else.
Option 1 is better: it keeps the pinned tree immutable, which is what the pin is for, and it means a `plugin.register` gate of the kind discussed in #91870 can check the tree at registration with nothing to ignore.
### Error Messages/Logs
```shell
❯ promptsign verify ~\.claude\plugins\cache\promptsign\promptsign\0.3.5
...
Error: Exit code 2
FAIL promptsign@0.3.5 signer: https://github.com/PromptSign/promptsign-plugin/.github/workflo
ws/sign.yml@refs/tags/promptsign--v0.3.5
- error: unlisted file present: .in_use/42644
at C:\Users\\.claude\plugins\cache\promptsign\promptsign\0.3.5
Verification failed (exit code 2). The PromptSign plugin cache has content that doesn't match the
signed manifest:
Signer: https://github.com/PromptSign/promptsign-plugin/.github/workflows/sign.yml@refs/tags/promp
tsign--v0.3.5
Failure reason: Two unlisted files are present in the .in_use/ directory:
- .in_use/42644
These files were not included in the signed manifest, so the integrity check failed. They appear
to be temporary lock or state files. You may need to clean up this cache directory or check if
these files were added after the plugin was installed.
The host-written '.in_use' entry with a later mtime than every published file:
dir /a %USERPROFILE%\.claude\plugins\cache\promptsign\promptsign\0.3.5
Volume in drive C is ...
Volume Serial Number is ...
Directory of C:\Users\\.claude\plugins\cache\promptsign\promptsign\0.3.5
09/09/2026 08:18 AM .
09/09/2026 08:17 AM ..
09/09/2026 08:17 AM .claude-plugin
09/09/2026 08:17 AM 761 .gitattributes
09/09/2026 08:17 AM .github
09/09/2026 08:17 AM 308 .gitignore
09/10/2026 10:25 AM .in_use
09/09/2026 08:17 AM .promptsign
09/09/2026 08:17 AM hooks
09/09/2026 08:17 AM 11,369 LICENSE
09/09/2026 08:18 AM node_modules
09/09/2026 08:17 AM 4,816 package-lock.json
09/09/2026 08:17 AM 781 package.json
09/09/2026 08:17 AM 8,512 README.md
09/09/2026 08:17 AM scripts
09/09/2026 08:17 AM skills
09/09/2026 08:17 AM test
09/09/2026 08:17 AM trust
...
```
### Steps to Reproduce
1. `/plugin marketplace add PromptSign/promptsign-plugin`
2. `/plugin install promptsign@promptsign`
3. Start a Claude Code session and leave it open.
4. In a second terminal:
`dir /a /s %USERPROFILE%\.claude\plugins\cache\promptsign\promptsign\0.3.5`
5. Observe `.in_use\` inside the versioned directory with a newer mtime than every published file.
6. Optional, for `.orphaned_at`: install a plugin, let it update to a newer version, then look in the older version directory.
7. Run any tool that checks the tree against a complete file list (e.g. `promptsign verify ~\.claude\plugins\cache\promptsign\promptsign\0.3.5`). It reports the host's file as an unlisted addition.
### Claude Model
Not sure / Multiple models
### Is this a regression?
I don't know
### Last Working Version
_No response_
### Claude Code Version
v2.1.267
### Platform
Anthropic API
### Operating System
Windows, macOS
### Terminal/Shell
Windows Terminal
### Additional Information
_No response_
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
Start with the `/plugin install` flow and the session bookkeeping that creates `.in_use/` and `.orphaned_at` under `~/.claude/plugins/cache////`; reproduce the behavior with the listed Windows directory commands. Check the `plugin.register` gate discussed in #91870 and run `promptsign verify` against the cached version. Done means the installed version tree remains publisher-only and the install-time integrity check still passes after sessions and updates.
索引モデルが issue の本文から書いたものです。
評価
- 領域
- cli, security
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 活発
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 45/100