Prevent monitor status TCC prompts in Git-Same 3.2.0

.claude/CLAUDE.md

@@ -43,7 +43,10 @@ Git-Same is a Rust CLI + TUI + macOS Tauri app that discovers GitHub org/repo st
 
 **Commands:** `init`, `setup`, `sync`, `status`, `scan`, `workspace {list,default}`, `reset`, `monitor` (alias: `daemon`), `refresh`.
 
-**Why `monitor` is a CLI subcommand and not solely a Tauri-host responsibility:** the LaunchAgent invokes the managed helper as `git-same monitor --foreground --managed`, the cask installs it through the hidden `--install-agent` / `--remove-agent` modes, non-cask installs (`cargo install`, the homebrew formula) ship only the binary, `--status` / `--start` / `--stop` / `--uninstall` are the supported control surface, and a future Linux file-manager extension would talk to the same `gisa monitor` over the same Unix socket. The CLI handler is a thin shim (~140 lines); the loop itself lives in `git-same-core::monitor`.
+**Why `monitor` is a CLI subcommand and not solely a Tauri-host responsibility:** the LaunchAgent invokes the managed program as `<program> monitor --foreground --managed`, the cask installs it through the hidden `--install-agent` / `--remove-agent` modes, non-cask installs (`cargo install`, the homebrew formula) ship only the binary, `--status` / `--start` / `--stop` / `--uninstall` are the supported control surface, and a future Linux file-manager extension would talk to the same `gisa monitor` over the same Unix socket. The CLI handler is a thin shim; the loop itself lives in `git-same-core::monitor`, and `monitor::Options::from_config` / `monitor::default_shutdown_signal` are shared with the app.
+
+**Why an app-owned LaunchAgent execs `Git-Same.app/Contents/MacOS/git-same-app` and not the helper copy:** macOS TCC attributes a launchd-spawned process to its bundle only when the executable is the bundle's `CFBundleExecutable`. A copy of `Contents/Helpers/git-same` under `~/Library/Application Support` is a separate, path-based TCC identity, so a Full Disk Access grant for "Git-Same" never reaches a monitor started through it. `monitor_agent::source` therefore classifies an app-bundle caller as an **in-place** install: nothing is copied, and the rendered plist names the bundle executable. `crates/git-same-app/src/monitor_mode.rs` runs the same core loop headlessly (no Tauri, no window, no Dock icon) when argv[1] is `monitor`. CLI owners (cargo, the formula) keep the copy-into-managed-root install and its path-based identity. The expected program is derived from `owner_kind`, not persisted, so an agent installed by an older build is re-rendered onto the bundle executable the next time the app runs its startup recovery.
+
 
 ### Engine modules (`crates/git-same-core/src/`)
 
@@ -114,7 +117,9 @@ Three non-obvious traps in `macos/GitSameBadges/`. Each one silently breaks badg
 
 3. **Google Drive's FinderSync poisons the badge-rendering pipeline.** When `com.google.drivefs.finderhelper.findersync` is enabled, peer FinderSync extensions render no badge image even after Finder calls `setBadgeIdentifier`. Confirmed in this environment: badges only began appearing after the user disabled Google Drive in System Settings → Login Items & Extensions. Other peers (Keka, Synology, Dropbox) coexist fine. There is no code fix; document the workaround and surface it in the in-app self-check if you can.
 
-`scan_roots` and `show_ambient`: defaults are `["~"]` / `false`. Never re-enable `show_ambient = true` with `~` in `scan_roots`: Finder refuses to call `requestBadgeIdentifier` on extensions whose `directoryURLs` contain the home folder (separate issue from the three above).
+4. **Full Disk Access is per executable, and the extension is not the process that needs it.** The appex does zero I/O outside its app-group container and has never triggered a TCC prompt. The monitor is what walks workspace roots, reads `/Volumes`, watches FSEvents, and writes `Icon\r`, so it is the process that needs FDA. `git-same-core::macos::full_disk_access::probe()` (opens the user TCC.db; success proves the grant, EPERM means denied, never prompts) is stamped into `status.json` as `full_disk_access` by the monitor and read by the app, whose `enable_finder_extension` command refuses to set the pluginkit election until the gate passes. macOS applies a new grant on process start: the app must be relaunched and the monitor restarted (the app does the latter automatically).
+
+`scan_roots` and `show_ambient`: defaults are `["~"]` / `false`. Never re-enable `show_ambient = true` with `~` in `scan_roots`: Finder refuses to call `requestBadgeIdentifier` on extensions whose `directoryURLs` contain the home folder (separate issue from the four above).
 
 ## Workspace folder branding (macOS)
 

.github/workflows/S1-Test-CI.yml

@@ -192,7 +192,7 @@ jobs:
           prefix-key: v1-rust-no-bin
 
       - name: Install cargo-tarpaulin
-        uses: taiki-e/install-action@v2
+        uses: taiki-e/install-action@v2.87.8
         with:
           tool: cargo-tarpaulin
 

.github/workflows/S2-Release-GitHub.yml

@@ -65,7 +65,7 @@ jobs:
           prefix-key: v1-rust-no-bin
 
       - name: Install cargo-tarpaulin
-        uses: taiki-e/install-action@v2
+        uses: taiki-e/install-action@v2.87.8
         with:
           tool: cargo-tarpaulin
 

Cargo.toml

@@ -7,7 +7,7 @@ members = [
 resolver = "2"
 
 [workspace.package]
-version = "3.1.2"
+version = "3.2.0"
 edition = "2021"
 authors = ["Manuel Gruber"]
 license = "MIT"

crates/git-same-app/Cargo.toml

@@ -28,6 +28,8 @@ tauri = { version = "2", features = [] }
 tauri-plugin-dialog = "2"
 tokio = { workspace = true }
 toml = { workspace = true }
+tracing = { workspace = true }
+tracing-subscriber = { workspace = true }
 
 [dev-dependencies]
 tempfile = { workspace = true }