Document the Chat Uploads setting that routes attachments to the terminal

A terminal connection now carries a Chat Uploads field, and the interface
gives no explanation of what its Filesystem option does. Choosing it changes
where every file attached in the chat input ends up. The file is written into
the terminal's current working directory rather than uploaded to Open WebUI,
no text is extracted from it, no retrieval runs over it, and the model is
given the path so it can open the file with the terminal's own tools. An
operator reading the connection form has no way to tell that from the label,
and a user whose attachment stops behaving like a document has no way to tell
why.

The connection guide gains a section covering both values and the four
consequences that catch people out: the model no longer has to declare file
upload support, the path reaches the model only when it is using native
function calling in a saved conversation, an image is written to the working
directory instead of being shown to the model, and Open WebUI's file size and
attachment count limits are still enforced. The file browser page picks up
the chat input as a second route into the working directory it displays, and
the environment variable reference describes the matching connection config
key for deployments configured at startup.

This behaviour exists only on the application's dev branch and is in no
tagged release, so it is documented on dev alone.

docs/features/open-terminal/file-browser.md

@@ -92,6 +92,10 @@ Navigate to the folder you want first, then drag and drop. The file uploads to w
 
 Uploading is switched off in a folder marked **Read-only**, and dropping files onto one does nothing.
 
+### From the chat input
+
+Files attached in the chat input normally go to Open WebUI, where their text is extracted for the model to read. An administrator can point them at the terminal instead, by setting the connection's **Chat Uploads** to `Filesystem`. Attachments then land in the current working directory and show up here like anything else, and the model opens them with the terminal's tools rather than reading extracted text. See [Chat Uploads](/features/open-terminal/setup/connecting#chat-uploads).
+
 ---
 
 ## Downloading files

docs/features/open-terminal/setup/connecting.md

@@ -44,6 +44,7 @@ Open Terminal has its **own section** under Integrations. Don't add it under "Ex
 | **URL** | `http://localhost:8000` (or `http://open-terminal:8000` if using Docker Compose) |
 | **API Key** | The password you chose during installation |
 | **Auth Type** | Leave as `Bearer` (the default) |
+| **Chat Uploads** | Leave as `Default`. [Chat Uploads](#chat-uploads) covers what `Filesystem` changes |
 
 ![Connection form filled in with URL and API key](/images/open-terminal-connection-form.png)
 
@@ -117,6 +118,27 @@ If you need to test a connection without admin access, you can add one from **Se
 
 ---
 
+## Chat Uploads
+
+**Chat Uploads** on the connection form decides where a file attached in the chat input goes while that terminal is selected.
+
+`Default` uploads the file to Open WebUI, extracts its text and hands the model the contents to read, through retrieval or in full depending on the chat's settings. It is what a connection nobody has touched does, and what happens with no terminal selected at all.
+
+`Filesystem` writes the file into the terminal. It lands in the terminal's current working directory, the same place the [file browser](../file-browser) is showing, and appears there straight away. Nothing is stored in Open WebUI, no text is extracted and no retrieval runs, so the model never receives the contents. It receives the path and opens the file with the terminal's own tools, the way it reads anything else in the workspace.
+
+A zip archive, an SQLite database, a video file, an export far larger than a context window: text extraction has little to offer for any of them, and a shell handles all of them. Attaching one this way puts it where the commands the model runs can reach it.
+
+Four things change with it:
+
+- **The model no longer needs to support file upload.** With `Default`, attaching a file while a model without that capability is selected reports "Model(s) do not support file upload" and nothing uploads. With `Filesystem` the file never reaches the model as an attachment, so that check does not run.
+- **The model is told the path only when it can act on it.** Open WebUI passes the paths of attached files to the model alongside the message when the model is using native function calling in a saved conversation. Set the model to [Legacy](#8-enable-native-function-calling) function calling, or turn its **Builtin Tools** capability off, and the file still reaches the terminal while the model is left without its location.
+- **Images go the same way.** An image attached to a saved conversation is written to the working directory rather than passed to the model as a picture. Open WebUI still checks it against the selected models' image support first, so a model with no vision support turns it away at the input.
+- **Upload limits still apply.** The maximum file size and the maximum number of attachments configured for Open WebUI are both checked before anything is sent, so `Filesystem` does not lift them.
+
+The field is on every terminal connection, the ones an administrator adds and the ones you add under your own settings.
+
+---
+
 ## Troubleshooting
 
 ### "Connection failed" or timeout

docs/reference/env-configuration.mdx

@@ -1707,6 +1707,8 @@ For an orchestrator connection, set `policy_id` to route every terminal request
 
 `config.contexts` gives an orchestrator connection a separate workspace per chat or per automation, or withholds it from either, with the keys `chat` and `automation`. It is ignored on connections that are not orchestrator ones. See [Terminal Contexts](/features/open-terminal/terminals/orchestration/contexts) for the values, the admin controls and the capacity trade-off.
 
+`config.chat_uploads` decides where a file attached in the chat input goes while this terminal is selected. The default, `default`, uploads it to Open WebUI and extracts its text for the model to read. `filesystem` writes it into the terminal's current working directory instead, with no text extraction, no retrieval and nothing stored in Open WebUI; the model is given the path and opens the file with the terminal's own tools. Any other value is read as `default`. See [Chat Uploads](/features/open-terminal/setup/connecting#chat-uploads).
+
 `auth_type` accepts `bearer` (send `key` as the bearer token), `session` (send the calling user's own Open WebUI credentials), `system_oauth` (send the user's OAuth access token) and `none`. Use `session` for an orchestrator connection when the orchestrator runs with `TERMINALS_OPEN_WEBUI_URL` set, so it validates each request against the identity of the user who made it.
 
 :::tip Helm chart auto-configuration