An assistant with the guardrails you set

What happens when you ask a question

1. 1

   Choose the target

   Pick one tab, or all open terminals. The target cannot change while the assistant is answering.

2. 2

   Ask in your own words

   For example, “check disk usage on the open server”. Enter sends; Shift+Enter adds a line.

3. 3

   The model looks first

   It gets safe metadata about the tabs in scope and may read their output. It never gets whole tabs automatically.

4. 4

   You approve the change

   Anything that connects, types, runs or touches a file shows a card with the session, address and exact command.

5. 5

   Gimotty types it for you

   The command goes into your existing session, and Gimotty waits for the real output.

6. 6

   The answer uses real output

   Tables and code blocks can be copied. Stopping the chat cancels pending model calls and approvals.

What needs your approval

Three answers to every request

Approve once

Runs this call only.

Allow this conversation

The same tool on the same terminal or session runs without asking until you clear the chat.

Reject

Nothing runs, and the model is told you said no.

A request left unanswered for 5 minutes is marked “Approval expired · not run” and recorded in the audit log.

What your model receives

If you let the assistant read a terminal, server information in that output goes to the provider you chose. Pick the model with that in mind; a local model keeps it on your network.

Supported model connections

• Remote servers must use HTTPS. Plain HTTP is allowed for loopback, and for private addresses (10.x, 172.16–31.x, 192.168.x, fc00::/7) after you turn it on and confirm a warning.
• Redirects are not followed. Gimotty never picks or downloads a paid model for you.
• API keys can stay in memory for the session, come from an environment variable, or be saved with Windows DPAPI for your account, tied to the base URL they were saved for.

Decide what AI can see, folder by folder

Each saved session or folder has an AI access level. The assistant and the MCP server both follow it.

The MCP server

Run gimotty mcp from any MCP client that starts local stdio servers, such as Claude Desktop, Claude Code or Cursor. It opens no network port.

16 tools in four groups

Look up

sessions_list sessions_get diagnostics

Terminal

terminal_open terminal_list terminal_read terminal_wait terminal_write terminal_resize terminal_close

Command

command_execute

Files

file_list file_read file_write file_download file_upload

• Up to 8 requests run at once, with cancellation and progress notifications.
• terminal_wait waits for a pattern or a quiet screen, so clients do not poll.
• Without --allow-local, file tools can only use Gimotty’s transfers folder on your PC.
• MCP never asks for or stores passwords, and never reads the vault. It connects with keys or an SSH agent.

The audit log

Every connection, input, resize, close, command and file call is written to audit/audit-YYYY-MM.jsonl in your Gimotty folder, with the time, source (assistant or MCP), client, session, target, command or path, result, exit code and duration. Open it from the MCP and automation screen or with gimotty audit.

Call tools without a model

The assistant’s menu can run any MCP tool directly with JSON arguments, under the same permission checks. Useful for testing access rules before you connect a model.