Follow-ups from #38: doctor permission check, docs gap, and token-resolution cleanup

[DevRohit06]

Items surfaced while reviewing #38 that were deliberately left out of that PR's scope. Roughly in priority order.

1. Existing loose config files are never tightened

#37 asked to "automatically tighten permissions if existing files or directories had looser permissions," but tightening only happens inside save_config(). A user who already has ~/.discli/config.json at 0644 and never runs config set again stays exposed indefinitely — which is most of the population the issue was about.

doctor is the documented first-stop diagnostic and was already touched by #38, so a check that stats the config file and reports a loose mode is the natural fix. Tightening silently on read is the other option, but a chmod as a side effect of load_config() is surprising; the doctor check is the better shape.

2. Dangling code block in docs/getting-started/configuration.mdx

The edit removed the lead-in sentence ("This writes to ~/.discli/config.json:") along with the Set token. output, leaving a bare json block after the bash command with nothing introducing it.

3. CLAUDE.md not updated for DISCORD_TOKEN

• Line 39 lists only DISCORD_BOT_TOKEN under Environment Variables.
• Line 44's note — "examples/meeting_transcriber.py reads DISCORD_TOKEN, not DISCORD_BOT_TOKEN" — changes meaning now that DISCORD_TOKEN is a supported fallback rather than a mismatch.

The four-level resolution order is also worth a line there, since it is the kind of non-obvious ordering decision CLAUDE.md exists to record.

4. test_setup_reuses_discord_token_when_confirmed doesn't test its name

It asserts exit_code == 0 and that "1. Bot token" printed — neither of which depends on DISCORD_TOKEN being set at all. The wizard fixture already captures saves, so assert wizard["token"] == "discord-token" is available.

Related, and worth a deliberate decision rather than a drive-by: confirming that candidate copies the env token into config.json. That is pre-existing behaviour for DISCORD_BOT_TOKEN, but the docs pitch env vars as the way to "avoid writing secrets to disk" and the wizard quietly does the opposite. #38 doubled the surface where that happens.

5. Token resolution is implemented twice

cli.py:78-79 and client.py:28-30 each implement the config → DISCORD_TOKEN fallback. Every production call site is resolve_token(ctx.obj.get("token"), {}) — an empty dict — so client.py's config branch was already dead in-tree and its env branch is reachable only from tests. Two places to keep in sync for one rule, with only one of them live.

6. Smaller cleanups

• doctor.py: the token = os.environ.get(...) or load_config().get(...) or os.environ.get(...) line is duplicated verbatim at two sites and runs 108 chars. A small shared helper keeps them from drifting apart.
• config.py uses sys.stderr.write + explicit flush where the rest of the codebase uses click.echo(..., err=True).
• save_config() is still non-atomic (pre-existing, not a regression from feat(security): enforce 0600 config permissions and support DISCORD_TOKEN fallback #38). os.open a temp in the same directory at 0600 → write → os.replace would get atomicity, never expose content, and remove the fchmod dance entirely. Optional, but the function was already being rewritten once.

Not in scope here

The fd double-close and the silent unprotected-write fallback from #38 were fixed in e2057f8 before merge.

[DevRohit06]

Two more, both surfaced by the failed v0.13.0 release run (34042455964).

7. Worth a CLAUDE.md gotcha: patching os.chmod does not intercept Path.chmod on 3.10

save_config() calls path.parent.chmod(). On Python 3.10 pathlib routes that through a _NormalAccessor that binds os.chmod at import time, so monkeypatch.setattr(os, "chmod", ...) never intercepts it — the code under test runs the real chmod, the warning never fires, and the assertion reads an empty stderr. The accessor layer was removed in 3.11, so the same test passes on 3.11/3.12/3.13.

Verified directly:

py3.10  has _NormalAccessor=True   os.chmod patch intercepts Path.chmod=False
py3.12  has _NormalAccessor=False  os.chmod patch intercepts Path.chmod=True

Fixed in 780a300 by patching Path.chmod instead, which intercepts on every supported version. Since 3.10 is in the release matrix, this trap will recur for anything else that tests a Path method by patching the os module — worth a line in the Gotchas section.

8. This is an argument for CI on PRs

CLAUDE.md notes there is no CI on pushes or PRs — tests run only on v* tags. That is precisely why a 3.10-only failure got discovered by a release tag rather than by the PR that introduced it: the change was correct on the maintainer's interpreter and on three of the four matrix legs.

The release gate did its job — build and pypi-publish were skipped, so nothing shipped — but the cost was a burned tag and a retag. Running the existing matrix on pull_request would have caught it in #38. It is the same workflow file, just a second trigger.