You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes. When using Anthropic models, all input tokens are cached on Anthropic's servers.
17
17
</Accordion>
18
18
19
+
<Accordiontitle="Can I disable Open SWE from creating an issue when I submit a request?">
20
+
Yes. There's two ways to disable Open SWE from creating an issue when you submit a request:
21
+
22
+
1. Toggle the 'eye' icon in the main chat area when submitting a request.
23
+
2. In the configuration tab in settings, toggle the 'Should Create Issue' switch.
24
+
25
+
By default, it's set to `true`. By modifying this setting in the configuration tab, all runs will default to that setting. You may override this setting on a per-run basis by toggling the 'eye' icon in the main chat area.
26
+
</Accordion>
27
+
19
28
<Accordiontitle="My run failed midway through. What now?">
20
29
We're sorry you're experiencing this! Open SWE will automatically commit any changes it makes to a draft pull request. Please check the draft pull request and make any necessary changes.
-**Access**: User-controlled via settings page in UI
42
+
-**Security**: AES-256-GCM encrypted + explicit user consent required to pass them to the development server
35
43
36
-
**By default, your API keys are never exposed to sandbox environments.** They're only used for LLM initialization and system setup.
44
+
### When API Keys Are Exposed to Sandbox Environments
37
45
38
-
To enable keys in development servers (for testing LangGraph agents, Next.js apps, etc.):
46
+
Your API keys are **never automatically exposed** to sandbox environments. Exposure requires explicit user consent.
39
47
40
-
1. Manually toggle "Include in Dev Server" for each key
41
-
2. Key becomes available as environment variable in sandbox
42
-
3. You control which keys are exposed
48
+
You may wonder, why does the sandbox environment even need API keys? We've designed Open-SWE to be your junior dev. Part of development is testing code in real-time. **Open-SWE has the ability to spin up development servers that can run your LangGraph agents, Next.js apps, Flask servers, and more, all within the sandbox its running in.** If you think this option can be useful, please review what it means to pass your keys to the sandbox.
43
49
44
50
<Note>
45
-
Use separate development API keys with limited permissions instead of production keys when enabling sandbox access.
51
+
Consider using separate development API keys with limited permissions instead of your production keys when enabling sandbox access. This reduces the impact of potential exposure while maintaining functionality.
46
52
</Note>
47
53
48
-
## Security & Isolation
54
+
**Default Behavior (Secure):**
55
+
- API keys are only used for LLM model initialization & setting up Daytona using your own key, if you passed it
56
+
- Keys are NOT available as environment variables in sandboxes or accessible to LLMs
57
+
- Each key has `allowedInDev: false` by default
58
+
59
+
**When You Enable "Include in Dev Server":**
60
+
- You manually toggle the switch for each API key
61
+
- Key becomes available as an environment variable in sandbox
62
+
- You maintain control over which keys are exposed
63
+
64
+
## Sandbox Security & Isolation
65
+
66
+
### Container Isolation
67
+
68
+
Each user session runs in a completely isolated Daytona container with multiple security boundaries. These containers can modify the code in your repo on a new branch and don't exchange information across sessions.
69
+
70
+
<Accordiontitle="Isolation Details">
71
+
**Container Isolation:**
72
+
- Separate container per user session
73
+
- No shared file systems between containers
74
+
- Container-level resource limits and quotas
75
+
76
+
**Process Isolation:**
77
+
- User environment variables vs system environment variables
78
+
- Sandboxed processes cannot access host system or code
49
79
50
-
Each session runs in an isolated Daytona container that:
51
-
- Cannot access other user sessions
52
-
- Automatically deletes after 15 minutes of inactivity
53
-
- Has no persistent storage across sessions
80
+
**Temporal Isolation:**
81
+
- Automatic deletion after 15 minutes of inactivity
82
+
- No persistent storage across sessions
83
+
- Fresh environment for each new session
54
84
55
-
<Accordiontitle="Detailed Isolation Features">
56
-
-**Container**: Separate container per user session
57
-
-**File System**: No shared file systems between containers
58
-
-**Process**: Sandboxed processes cannot access host system
59
-
-**Network**: Containers cannot communicate with each other
60
-
-**Temporal**: Fresh environment for each session
85
+
**Network Isolation:**
86
+
- Containers cannot communicate with each other
61
87
</Accordion>
62
88
89
+
## Data Handling & Access Control
90
+
63
91
<Warning>
64
-
When enabling "Include in Dev Server", the AI agent may inadvertently expose environment variables in generated code or logs. Only enable when necessary.
92
+
When enabling "Include in Dev Server" for API keys, you're expanding the attack surface of your credentials. AI agent may inadvertently expose environment variables in generated code or logs. Only use this feature when necessary for development server monitoring.
65
93
</Warning>
66
94
67
-
## Best Practices
95
+
### Development Environment Exposure Risks
96
+
97
+
You should only use this feature if you find it useful to monitor development servers. We recommend not using your main keys and having access control for keys that you pass to sandbox environments.
98
+
99
+
While the Open-SWE UI and agent exchange these using encryption, **LLM may leave environment variables exposed in the code.**
68
100
69
-
- Use minimum required permissions for each API key
101
+
## Security Best Practices
102
+
103
+
Our team loves using Open-SWE internally and we recommend the following best practices:
104
+
105
+
- Use the minimum required permissions for each API key
70
106
- Regularly rotate your API keys
71
-
- Use separate development keys instead of production keys for sandbox access
72
-
- Only enable "Include in Dev Server" when necessary
73
-
- Never enable sandbox access for production database credentials
74
-
- Review generated code for exposed environment variables before deploying
75
-
- Monitor "Last Used" timestamps in settings
107
+
- Only enable "Include in Dev Server" when necessary for specific tools
108
+
- Monitor the "Last Used" timestamps in settings
109
+
- Consider using separate development keys instead of production keys for sandbox environments
110
+
- Never enable sandbox access for production database credentials or high-privilege API keys
111
+
- Review generated code for accidentally exposed environment variables before deploying
0 commit comments