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

Open
  • Is something wrong?
#219 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Domain
devtools

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Python
Stars
5.6k
Forks
344
Avg merge
17h 41m
Merged PRs (30d)
73

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/TokenEconomizer

All issues in microsoft/TokenEconomizer

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.