fix(miner): isolate cli agent credential paths

[JSONbored]

Motivation

• The CLI coding-agent driver was inheriting HOME and XDG credential/config envs and spawning a prompt-injectable subprocess in the attempt worktree, which exposed local CLI credential stores to prompt injection.

Description

• Added a non-credential allowlist CODING_AGENT_ENV_ALLOWLIST and switched the driver to use it instead of the broader SUBPROCESS_CLI_ENV_ALLOWLIST so HOME/XDG_* paths are not inherited by default (packages/gittensory-engine/src/miner/cli-subprocess-driver.ts).
• Removed the direct import/use of SUBPROCESS_CLI_ENV_ALLOWLIST in the driver and call buildAllowlistedEnv(...) with the new allowlist so callers can still explicitly overlay an isolated HOME when needed.
• Extended the unit test in test/unit/cli-subprocess-driver.test.ts to assert parent HOME/XDG_CONFIG_HOME/XDG_DATA_HOME/XDG_STATE_HOME are not passed through while verifying explicit overlays (e.g. an injected HOME or session handle) continue to work.

Testing

• Ran the focused unit tests with npm test -- --run test/unit/cli-subprocess-driver.test.ts and the test file passed.
• Built the miner package with npm run build:miner and the build succeeded.
• Ran a coverage-enabled single-file run (npx vitest run test/unit/cli-subprocess-driver.test.ts --coverage.enabled true --coverage.reporter=text); the targeted tests passed but the repo-wide global coverage thresholds failed (this is expected when running a single test file against the repository-level coverage gates).

---

Codex Task

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	gittensory-ui	5544e9d	Commit Preview URL Branch Preview URL	Jul 11 2026, 06:43 AM

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.11%. Comparing base (bda42f7) to head (5544e9d).
⚠️ Report is 111 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4981   +/-   ##
=======================================
  Coverage   94.11%   94.11%           
=======================================
  Files         433      433           
  Lines       38494    38495    +1     
  Branches    14037    14037           
=======================================
+ Hits        36229    36230    +1     
  Misses       1604     1604           
  Partials      661      661           

Flag	Coverage Δ
shard-1	50.86% <100.00%> (?)
shard-2	29.19% <100.00%> (?)
shard-3	30.96% <50.00%> (?)
shard-4	28.87% <50.00%> (?)
shard-5	33.63% <50.00%> (?)
shard-6	41.29% <50.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ttensory-engine/src/miner/cli-subprocess-driver.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gittensory-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-12 08:23:09 UTC}

2 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · unstable

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This PR fixes a real security gap: the CLI coding-agent driver previously built its subprocess env from SUBPROCESS_CLI_ENV_ALLOWLIST, which includes HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, and XDG_STATE_HOME, so a prompt-injectable coding-agent subprocess (running inside an attacker-influenced attempt worktree) could reach the invoking host's real credential/config stores. The fix introduces a narrower CODING_AGENT_ENV_ALLOWLIST (cli-subprocess-driver.ts:53-67) that drops those four keys, and buildAllowlistedEnv (subprocess-env.ts) still lets a caller overlay an explicit isolated HOME via options.env, which the updated test confirms still works. The fix is at the correct layer (the allowlist that sources the env, not a downstream guard), and the test exercises both the default no-leak path and the explicit-overlay path with real assertions, not fabricated state. One open question: nothing in this diff confirms that the factory that constructs CliSubprocessDriverOptions in production actually supplies an isolated HOME by default now that it's no longer in the base allowlist — many coding-agent CLIs treat $HOME as required for config resolution, so if no caller overlays it, the CLI could start failing at runtime for a different reason than before this PR.

Nits — 5 non-blocking

• Verify the caller/factory that wires createCliSubprocessCodingAgentDriver (referenced as feat(miner-hands): CodingAgentDriver factory + provider-style config resolution #4289 in the comments) now passes an explicit isolated HOME via `options.env`, since HOME is no longer in the default allowlist and its absence could break CLIs that require $HOME to resolve config paths — I can't see that wiring in this diff.
• The PR description doesn't link an issue number for this security fix (only references sibling PRs feat(miner-hands): CLI-subprocess CodingAgentDriver (reuse SpawnFn/redactSecrets/EFFORT_TIMEOUT_MS pattern) #4266/feat(miner-hands): define the CodingAgentDriver interface seam #4262/feat(miner-hands): shared subprocess redaction/env-allowlist helper in gittensory-engine #4284/feat(miner-hands): git-worktree-per-attempt isolation primitive #4269 in code comments) — per repo convention, contributor PRs should close or clearly link an eligible open issue.
• The lowercase/uppercase proxy var duplication (`HTTPS_PROXY`/`https_proxy` etc.) in the new allowlist mirrors the existing SUBPROCESS_CLI_ENV_ALLOWLIST pattern, so it's consistent, but consider a shared base array (proxy/TLS/locale) that both allowlists extend to avoid future drift between the two lists.
• Add the originating issue link to the PR description so this maps cleanly to an eligible open issue per repo convention.
• Confirm and, if needed, document at the call site that HOME is always overlaid explicitly for the coding-agent driver now that it's excluded from the default allowlist.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 45 registered-repo PR(s), 37 merged, 411 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 45 PR(s), 411 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Ruby, Go, JavaScript, MDX, Shell, Solidity
• Official Gittensor activity: 45 PR(s), 411 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review