Security considerations, policies, and guidelines for the Coding Assistants application.
This document covers security aspects of:
- The desktop application (Tauri + React + Rust)
- The TCP remote control server
- The Android companion app
- LLM provider integrations
- File system operations
Coding Assistants uses Tauri 2's capability-based permission system. Only explicitly granted permissions are available to the frontend webview.
Current permissions (defined in src-tauri/capabilities/default.json):
| Permission | Purpose |
|---|---|
core:default |
Basic Tauri IPC functionality |
opener:default |
Open URLs and files with OS handler |
dialog:default |
Native file picker and message boxes |
No additional permissions (shell access, clipboard, filesystem, etc.) are granted to the webview. All privileged operations go through explicit Tauri commands.
┌──────────────┐ IPC (JSON) ┌──────────────┐
│ Webview │ ◄────────────────► │ Rust Process │
│ (Untrusted) │ │ (Trusted) │
└──────────────┘ └──────────────┘
- The webview (frontend) is treated as untrusted. It cannot directly access the filesystem, spawn processes, or make network connections.
- All privileged operations are mediated by the Rust backend through Tauri commands.
LLM providers are invoked via std::process::Command with explicit arguments, never through a shell:
// Correct: explicit arguments
Command::new("ollama").arg("run").arg(model_name)
// Never: shell invocation
Command::new("sh").arg("-c").arg(format!("ollama run {}", model_name))This prevents command injection attacks where malicious model names or inputs could execute arbitrary commands.
Resource file operations validate that paths are restricted to expected directories:
get_resource_contentverifies paths start with.agentbefore readingFileToolsoperates relative to the configured workspace directory- No path traversal (
../) should escape the workspace boundary
- User task descriptions are passed as string arguments to LLM processes, not interpolated into shell commands
- MCP configuration is parsed as JSON before use
- TCP protocol messages are deserialized from JSON with type-safe Rust structs
Content Security Policy is currently set to null in tauri.conf.json for development flexibility. For production deployments, this should be tightened:
{
"app": {
"security": {
"csp": "default-src 'self'; script-src 'self'"
}
}
}The TCP server (tcp_server.rs) listens on 0.0.0.0:5555 for remote control connections.
Current state:
- No authentication -- any device on the local network can connect
- No encryption -- communication is plaintext JSON over TCP
- No rate limiting -- no protection against connection flooding
Recommendations for production use:
- Only start the server when needed (it's off by default)
- Ensure your local network is trusted
- Consider using a VPN for remote access
Planned improvements (see ROADMAP.md):
- Token-based authentication
- TLS encryption
- Connection allowlisting
API keys for cloud LLM providers are stored in env/.env:
- The
env/directory is not gitignored by default -- be cautious about committing secrets - Keys are loaded at runtime via the
dotenvcrate - Keys are passed to external processes as environment variables, not command-line arguments (avoiding
/procexposure)
Recommendation: Add env/.env to .gitignore and use env/vars.env as a template only.
Agent responses may contain [[ASK_USER]] or [[ASK_AGENT:RoleName]] markers. These are parsed as control flow directives. If a malicious LLM response includes these markers, it could:
- Trigger unwanted user interaction dialogs
- Cause one agent to query another unexpectedly
Mitigations:
- Inter-agent communication requires explicit user authorization via the Authorization Modal
- Users can cancel tasks at any time
- Agent outputs are displayed in the Activity Log for review
The application does not automatically execute code generated by agents. All outputs are displayed as text. Users must manually copy and apply any suggested changes.
Task descriptions and agent outputs may be sent to cloud LLM providers. Be aware of:
- What data you include in task descriptions
- Which provider you're using (local vs cloud)
- Your provider's data retention policies
FileTools (file_tools.rs) provides sandboxed file operations:
pub fn read_file(&self, relative_path: &str) -> Result<String, String>
pub fn write_file(&self, relative_path: &str, content: &str) -> Result<(), String>- Operations are relative to
work_dir-- the user-selected workspace - The
read_file_absolutecommand exists for specific use cases but should be used sparingly
The .agent/ directory structure (prompts, rules, workflows) is scanned via walkdir:
- Only files within
.agent/prompts/,.agent/rules/, and.agent/workflows/are listed - Content reads are validated to ensure the path starts with
.agent
If you discover a security vulnerability, please report it responsibly:
- Do not open a public GitHub issue for security vulnerabilities
- Contact the maintainers privately through GitHub's security advisory feature
- Include a description of the vulnerability and steps to reproduce
- Allow reasonable time for a fix before public disclosure
Before submitting code changes, verify:
- No shell invocations (
sh -c,bash -c,cmd /c) - File paths are validated and sandboxed
- User input is not interpolated into command arguments
- Sensitive data (API keys, tokens) is not logged or exposed
- New Tauri commands are registered with minimal required permissions
- IPC payloads use typed Rust structs (no raw string parsing)
- TCP protocol changes maintain JSON schema validation