Hard to use across machines: state outside repo, absolute paths in generated launcher, per-repo config sprawl

未关闭
  • 哪里不对？
#219 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
15/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
活跃
领域
devtools

调研方向

This is a design discussion, not a single change: state location (~/.tokeneconomizer), the generated launcher ~/.tokeneconomizer/bin/te with its hardcoded plugin-cache path, and the per-repo .claude/settings.local.json deny rules are the places it touches. Settle the intended storage layout and runtime path resolution with the maintainers before any code is written; done means an agreed design, not a patch.

由索引模型根据 Issue 内容生成。

描述

Feedback after using TokenEconomizer 0.1.0 (Claude Code plugin, Windows) across several repositories on two PCs, with ~/.claude synced through git. I ended up uninstalling it. These are the problems that led to that.

1. Not friendly to cloud/git sync
  • Learned state lives in ~/.tokeneconomizer (repos/, index.json, sessions/, locks/), outside ~/.claude and outside the repository. It cannot travel with a synced config or with the repo, so every machine relearns from scratch.
  • Per-repo state folders have hashed names (e.g. my-repo-73d35aa8b6, plus .bak-<timestamp> copies), so they cannot be matched or merged across machines by a person.
2. Absolute paths baked into generated files
  • The launcher written at session start, ~/.tokeneconomizer/bin/te, is a script like exec 'C:\Users\<name>\.claude\plugins\cache\tokeneconomizer\tokeneconomizer\0.1.0\scripts\te' "$@". It hardcodes the plugin cache path including user name and plugin version, so it is only valid on one machine and breaks on every plugin update or on a different profile folder.
  • Please resolve the plugin location at runtime (e.g. via CLAUDE_PLUGIN_ROOT or relative to the script) instead of writing it into a generated file.
3. Hard to see what is enabled where
  • Per-repo behaviour is spread over several places: .claude/settings.local.json deny rules in each repo, an extraKnownMarketplaces entry in each project's .claude/settings.json, project-scope plugin installs, and the state under ~/.tokeneconomizer.
  • In two of my repos the tool pruning had silently added about 250 entries to permissions.deny (Artifact, scheduled-tasks, Teams/Outlook/SharePoint connectors, Power Automate tools, ...). Nothing in the project made it obvious why those tools were missing. Support for finding out which repos are affected was limited to a command that must be run inside each repo.
  • With a user-level install plus project-level installs, the plugin list shows the same plugin several times, which made it hard to tell which copy applies where.
Suggestions
  • Keep state inside the repo (or an opt-in, relocatable directory), in a readable, mergeable format.
  • No absolute paths in generated files.
  • One place that shows which repos are enabled and what has been pruned, and prune via an explicit, visible, reversible step rather than a large silent deny list.
主要语言
Python
星标
5.6k
派生
344
平均合并
17 小时 41 分钟
30 天内合并 PR
73

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/TokenEconomizer 的其他 Issue

查看 microsoft/TokenEconomizer 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。