Add transparent_mode to config.proto

[jp-bennett]

Adds another potential option for splitting layers with the client.

Summary by CodeRabbit

• New Features
  • Added a new LoRa configuration option for transparent modem mode.
  • When enabled, the device operates in a pass-through mode that transmits provided pre-encrypted frames verbatim and returns received frames in raw form through the API.

[github-actions]

The latest Buf updates on your PR. Results from workflow pull-request / build (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Jul 6, 2026, 2:10 PM

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 4c2a3001-b0a2-4b9c-bb25-1e56a2710222

📥 Commits

Reviewing files that changed from the base of the PR and between 9452d3a and 7f885c3.

📒 Files selected for processing (1)

• meshtastic/config.proto

🚧 Files skipped from review as they are similar to previous changes (1)

• meshtastic/config.proto

---

📝 Walkthrough

Walkthrough

Added a new boolean field, transparent_mode (field number 108), to LoRaConfig in the protobuf schema, along with a comment describing transparent LoRa modem behavior without mesh routing or encryption.

Changes

LoRaConfig transparent_mode field

Layer / File(s)	Summary
Add transparent_mode field meshtastic/config.proto	Adds bool transparent_mode = 108; to LoRaConfig with a comment explaining raw frame passthrough behavior and the absence of mesh routing or crypto.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Related PRs: None identified.

Suggested labels: proto, enhancement

Suggested reviewers: None identified.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description is too brief and misses the required PR summary, related issue, and checklist details from the template.	Expand it to the template sections, especially What does this PR do?, the related issue link, and the checklist items.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly states the main change: adding transparent_mode to config.proto.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jp-bennett-patch-1

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

meshtastic/config.proto (1)

1253-1258: 🔒 Security & Privacy | 🔵 Trivial

Confirm gating for a field that disables mesh encryption/routing.

transparent_mode bypasses both mesh routing and encryption/decryption, and LoRaConfig is transported through ChannelSet.lora_config (meshtastic/apponly.proto) which backs shareable channel configs/QR codes. Since this schema change alone doesn't show how the setting is gated in firmware/client, worth confirming that enabling it requires appropriate authorization (e.g., admin session) rather than being settable via casual channel-config exchange, given it fully disables encrypted, routed mesh transport.

Defines the app-only ChannelSet API contract that includes a Config.LoRaConfig lora_config field.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@meshtastic/config.proto` around lines 1253 - 1258, The new transparent_mode
field in LoRaConfig disables encryption and mesh routing, so it must not be
freely settable through ordinary ChannelSet/lora_config exchange. Confirm and
enforce the existing authorization gate in the firmware/client path that applies
Config.LoRaConfig updates, and require an admin-authorized session (or
equivalent privileged flow) before transparent_mode can be enabled; if needed,
update the handling in the LoRaConfig/ChannelSet application code so this field
is rejected or ignored unless the caller is privileged.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@meshtastic/config.proto`:
- Around line 1253-1258: The new transparent_mode field in LoRaConfig disables
encryption and mesh routing, so it must not be freely settable through ordinary
ChannelSet/lora_config exchange. Confirm and enforce the existing authorization
gate in the firmware/client path that applies Config.LoRaConfig updates, and
require an admin-authorized session (or equivalent privileged flow) before
transparent_mode can be enabled; if needed, update the handling in the
LoRaConfig/ChannelSet application code so this field is rejected or ignored
unless the caller is privileged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 200853ad-004e-4274-ba7f-360e26101b87

📥 Commits

Reviewing files that changed from the base of the PR and between 93b6436 and 9452d3a.

📒 Files selected for processing (1)

• meshtastic/config.proto