Auto-connect request: codeburn personal-files (ai-agent-session-logs)

Snapcraft forum post

Category: store-requests > privileged-interfaces Title: Auto-connect request: codeburn personal-files (ai-agent-session-logs)

Post body (everything inside the fence):

name: codeburn

description: CodeBurn is a local-first cost and usage tracker for AI coding
tools (Claude Code, Codex CLI, Cursor, Copilot, and 40 supported tools in
total). It reads the session logs those tools write on the user's machine and
turns them into itemized cost analytics by project, model, session, and pull
request. Everything is parsed locally; there are no accounts and no uploads.

snapcraft: The snapcraft.yaml is generated at build time by electron-builder;
the snap configuration (confinement, plugs, and the full attribute list below)
is in the repository at app/package.json ("snap" section), with the CI build
at .github/workflows/build-snap.yml.

upstream: https://github.com/getagentseal/codeburn

upstream-relation: I am the upstream author and maintainer; the snap is
published by the upstream project itself.

plugs:
  ai-agent-session-logs:
    interface: personal-files
    attributes:
      read:
        - $HOME/.claude
        - $HOME/.cline
        - $HOME/.codewhale
        - $HOME/.codex
        - $HOME/.copilot
        - $HOME/.cursor
        - $HOME/.deepseek
        - $HOME/.factory
        - $HOME/.forge
        - $HOME/.gemini
        - $HOME/.grok
        - $HOME/.hermes
        - $HOME/.kimi
        - $HOME/.kiro
        - $HOME/.kiro-server
        - $HOME/.lingtai
        - $HOME/.lingtai-tui
        - $HOME/.mux
        - $HOME/.omp
        - $HOME/.openclaude
        - $HOME/.pi
        - $HOME/.quickwork
        - $HOME/.qwen
        - $HOME/.vibe
        - $HOME/.zcode
        - $HOME/.config/Claude
        - $HOME/.config/Code
        - $HOME/.config/Code - Insiders
        - $HOME/.config/Cursor
        - $HOME/.config/Kiro
        - $HOME/.config/Open Design
        - $HOME/.config/VSCodium
        - $HOME/.config/github-copilot
        - $HOME/.config/manicode
        - $HOME/.local/share/zed
    request-type: auto-connection
    reasoning: Reading these directories is the application's core function,
      not an auxiliary permission. Each path is where one of the supported AI
      coding tools writes its session logs, and CodeBurn parses those logs
      locally to produce cost analytics. Access is read-only; the app's own
      configuration and cache live in the snap's private area, so no write
      access is requested. Without auto-connection the app installs but shows
      empty data until the user runs the manual connect command, which for a
      first-run experience is indistinguishable from the app being broken.
      Note the store currently also blocks the upload itself with a
      human-review-required allow-installation constraint, so this request
      covers installation as well. Context: this snap was moved from a classic
      confinement request to strict confinement with personal-files following
      feedback in my earlier store-requests topic ("Classic confinement
      request: codeburn").

This request has been added to the queue for review by the @reviewers team.

Hey @ReshamJoshi ,

A couple of things to work through before auto-connection though. The main one: the reasoning describes these as “where each tool writes its session logs,” but the paths requested are the tools’ entire top-level directories, not their log subdirectories. $HOME/.claude, $HOME/.codex, $HOME/.config/github-copilot and similar hold each tool’s full configuration and in several cases credentials or tokens, not only usage logs, and personal-files read is recursive, so this grants read of everything under those roots, which is concerning

Question to you: Can the paths be scoped to the actual log subdirectories rather than the tool roots? Where a tool keeps its session data in a subpath? requesting that instead of the whole root would preserve your functionality while dramatically reducing the credential-exposure surface.

Second, on auto-connection specifically: personal-files auto-connect is normally reserved for directories the snap owns and CodeBurn owns none of these, they’re other vendors’ directories. That’s not automatically disqualifying given the read-only core-function case, but it’s why auto-connecting isn’t a routine yes. I wouldd be comfortable supporting auto-connection on a tightened, log-subdirectory-scoped path set; I am more hesitant to auto-connect recursive read of every tool’s full state directory..

for now, +1 for the manual-connection on these directories having personal-files read access, and we cna discuss auto-connection once the paths are scoped given that Publisher vetting is successful.

thanks

Thanks, this is a fair catch and you’re right. Those roots hold configuration and in some cases credentials, not just logs, and requesting them recursively was over-broad on my part.

Yes, the paths can be scoped. I went through what each provider actually opens, and almost all of them read a subdirectory rather than the root: .claude/projects, .codex/sessions and .codex/archived_sessions, .copilot/session-state, .cline/data, .vibe/logs/session, .openclaw/agents, .omp/agent, .pi/agent, .hermes/profiles, .mux/sessions, and so on. Two need only a single file, .forge/.forge.db and .zcode/cli/db/db.sqlite.

the .config entries tighten the most. For the VS Code family I only need User/globalStorage/saoudrizwan.claude-dev, rooveterinaryinc.roo-cline, kilocode.kilo-code and GitHub.copilot-chat, plus User/workspaceStorage, rather than all of .config/Code. Cursor is a single file, User/globalStorage/state.vscdb

One thing I should call out explicitly rather than have it buried in a root. Alongside the log directories, CodeBurn reads $HOME/.claude/.credentials.json, read-only. It uses the token already stored there to call Anthropic’s own usage endpoint so the app can display the user’s current plan utilization, which is the same thing Claude Code itself does with that file. It is never written, never transmitted anywhere except to Anthropic, and never leaves the machine. I would rather request that one file openly than have it silently included in a directory grant.

Codex has an equivalent feature, but it requires read-write on $HOME/.codex/auth.json because we refresh and write back the token. I do not think a store-distributed snap should hold write access to another vendor’s credential file, so I am dropping the Codex live-quota feature from the snap build entirely. Codex usage and cost analytics still work, since those come from session logs; only the live plan gauge is absent, and I will document that.

I also cannot scope .lingtai, where the vendor puts a per-agent directory above the log folder and personal-files takes no wildcards. Rather than keep a broad entry for one niche provider, I am dropping it too.

manual connection now works for me. I will submit the tightened set, and we can revisit auto-connection against that once publisher vetting is through.

Hey @ReshamJoshi

Thanks for the work done to tight the access requested. I’ll reach out via DM to start the publisher vetting

I’ve vet the publisher as member of the upstream project.

@ReshamJoshi would you be able to upload a new revision of your snap with the tightened set?

Hi @jslarraz thanks for completing the vetting, and the branch is removed.

A new revision with the tightened personal-files set is now uploaded to stable. Every entry is scoped to the specific subdirectory each tool’s session logs live in (e.g. $HOME/.claude/projects, $HOME/.codex/sessions) rather than the tool’s root; the one credential file we read ($HOME/.claude/.credentials.json, read-only, used only to call Anthropic’s usage endpoint for the live plan gauge) is declared openly as its own entry. Nothing requests write access.

Two notes for your review: Warp has no entry because our Warp support is macOS-only; and a couple of tools (crush, quickwork) keep a small registry file in the grant whose entries can point at project directories elsewhere those resolve through the normal home plug

Happy to adjust further if anything in the set still looks too broad. Thanks!

Hey @ReshamJoshi

Just reaching out to say that I would possibly need a couple extra days to find the time to properly assess all the requested directories. I’ll be back as soon as I can :slight_smile:

Hey I started to go through the list. And I have a couple of preliminary comments

  • $HOME/.claude/.credentials.json will need to be defined as an independent plug. I think this should be manually connected because of its sensitivity and the functionality it enables does not look critical to me.
  • $HOME/.cline/data as per https://docs.cline.bot/getting-started/config#configuration-directory-layout, data is still too broad. Could you please confirm if `$HOME/.cline/data/sessions/ would be enough? if not, what other paths are required?

Hi @jslarraz, thanks for going through the list.

$HOME/.claude/.credentials.json agreed. It only powers an optional plan/quota display, not the core session-log analytics, and the app already degrades gracefully without it. We’ll move it out of ai-agent-session-logs into its own plug (claude-quota-credentials, personal-files, read-only, that single file) with no auto-connect requested manual snap connect only.

$HOME/.cline/data narrowed. The parser reads exactly ~/.cline/data/tasks//ui_messages.json and api_conversation_history.json, so $HOME/.cline/data/tasks is the precise directory (Cline’s layout uses tasks/, not sessions/, for these transcripts). We’ll update the declaration to that path

I’ll push a revision with both changes. Happy to narrow anything else that stands out.

I’ve keep doing some research along side my favorite agent inspecting the source code. Whilst I didn’t finish yet, I have some more findings. It would be great if you could take a look at them

Antigravity: https://antigravity.google/docs/hooks/

  • ~/.gemini/antigravity-ide may not be used at all. Antigravity ide seems to use ~/.gemini/antigravity
  • Both antigravity and antigravity-cli can be scoped to ~/.gemini/antigravity/brain/ and ~/.gemini/antigravity-cli/brain/

Cline

Cursor

  • ~/.cursor/ai-tracking does not seem to contain session data

DeepSeek

Kiro

Thanks

Some more findings

Hermes

  • $HOME/.hermes/profiles may contain sensitive information, we would need something like $HOME/.hermes/profiles/*/state.db

Mux

  • I’m not sure $HOME/.mux/config.json contains sessions info

OMP

  • I think it should be further scoped to ~/.omp/agent/sessions/

Openclaw

  • similar to hermes, I think we would need something like ~/.openclaw/agents/*/sessions/**

Pi

  • Same as OMP, I think this can be further scoped to ~/.pi/agent/sessions/

VScode / copilot

  • I’m not sure $HOME/.config/Code/User/globalStorage/GitHub.copilot-chat contains session logs
  • I’m not sure $HOME/.config/github-copilot contains sessions logs either

Cursor

  • $HOME/.config/Cursor/User/globalStorage/state.vscdb seems to contain secrets, so I don’t think we can include it here

Thanks for the detailed pass. Revision (0.9.23) addresses every point; here is what changed, checked against the code paths the parsers actually open:

  • Narrowed to exact sub-paths wherever a narrower literal exists: .omp/agent/sessions, .pi/agent/sessions (auth.json is no longer covered), .cursor/ai-tracking/ai-code-tracking.db, the Cline/Roo/Kilo globalStorage//tasks directories, and the Antigravity conversations/implicit directories.

  • Removed ~/.config/github-copilot entirely. It contains OAuth credential files, and the only session data under it sits at a variable depth, so we dropped JetBrains Copilot support in the snap rather than grant the root.

  • Fixed a case error (GitHub.copilot-chat should be github.copilot-chat) and added a few paths the parsers read that were missing from the plug.

  • Kept as roots, with justification: Kiro (all four paths are real stores), antigravity-ide (real; there is no brain/ directory), ~/.mux/config.json (only a project-name map, no session content), ~/.deepseek/sessions (the CodeWhale CLI’s store), and ~/.lingtai / ~/.lingtai-tui (per-agent directories directly under the root, no fixed subpath).

Every remaining grant is a directory or file at least one parser opens; none covers a credential file. Happy to narrow further if any entry still looks wrong.