# Indent > Documentation for building and working with Indent. Index: https://docs.indent.com/llms.txt # Your new AI coworker > Indent is an AI coworker that completes tasks by executing real tool calls on a real computer, then reports what it did and how it verified the result. Source: https://docs.indent.com/ · Markdown: https://docs.indent.com/index.md Indent is an AI coworker. Hand it a task the way you'd hand one to a colleague: a bug to fix, a question about your data, a document to review. It works on a real computer with the tools your team already uses, so it can run commands, edit files, query your databases, and click through a browser, then shows you exactly what it did and how it verified the result. ### Indent for engineering ## Connect Indent to your environment Every system you connect gives Indent more context to draw on, and the effect compounds: the more of your stack it can see, the more of a task it can complete from start to finish. A development environment ties the rest together. With your application built and its services running, Indent can reproduce a problem, make the change across your codebase, and verify the fix against your real data and tools before it opens a pull request. Every step below is optional and can be done whenever you need it; each notes what Indent can't do until you complete it. 1. **Connect GitHub** Open [**GitHub in Integrations**](https://app.indent.com/integrations/github%3Aworkspace) and select **Connect personal account**, then **Install GitHub app** for the repositories you want. Indent clones them to read and write code, run and test your application, and open pull requests. Skip it and Indent can't read or write your code or open pull requests. See [Connecting GitHub](/connecting/github). 2. **Set up an environment** Pick a repository and select **Setup Environment** to build a reusable development environment: a Docker image, repositories to clone, build and runtime variables, and the services your application needs, with a check that confirms the setup works. Skip it and sessions run in a bare sandbox: your code is there, but not your running application, so Indent can't build the app, start its services, or exercise it in a browser. See [Setting up environments](/getting-started/environments). 3. **Connect your data and tools** From [**Integrations**](https://app.indent.com/integrations), connect the systems your work depends on: PostgreSQL, BigQuery, or ClickHouse databases, plus Datadog, Sentry, Notion, Linear, and HubSpot through MCP. Each integration's page shows its available organization and personal connection options. Skip it and Indent can't query your data or pull evidence from those tools until they're connected. See [Connecting MCP servers](/connecting/mcp-servers) and [Permissions and data](/administration/permissions-and-data). 4. **Bring Indent into Slack** Open [**Slack in Integrations**](https://app.indent.com/integrations/slack) and connect your workspace. Invite `@indent` to a channel with `/invite Indent`, then mention `@indent` to start. Skip it and you work with Indent in the web app instead of from Slack. See [Connecting Slack](/connecting/slack). 5. **Run your first task** Start a session in the [web app](https://app.indent.com) or mention `@indent` in Slack, and hand it a task in plain language: review an open pull request, answer a question about your data, or make a small code change. Indent does the work and reports what it did and how it verified the result. ## Give Indent any task - **Write and ship code** — Indent explores the codebase, makes the change, runs the tests, and opens a pull request. - **Query and analyze data** — Indent writes the query, returns the numbers, and plots them. - **Investigate an incident** — Indent follows an error through your logs, traces, and code to the root cause, then proposes a fix. - **Review pull requests** — Indent reads the diff, tests the change, and works with you in the comments to get it merged. ## Use Indent from anywhere - **Web app** — Start and manage your Indent sessions from the web, with file, query, and pull-request output rendered inline. - **Slack** — Mention `@indent` in a channel, or send a direct message. - **GitHub** — Indent reviews pull requests and replies in comment threads; mention it to continue in the thread. - **Desktop app** — Runs Indent on your own computer, in a folder you choose. ## Teach Indent to get better Indent works best with context. AGENTS.md, skills, and memories make relevant guidance reusable, so you spend less time repeating your codebase, conventions, and workflows. - **AGENTS.md** — Repository instructions kept with your code. Local desktop sessions load the root file automatically; in cloud sessions, ask Indent to read it. - **Skills** — Reusable workflows you commit to a repository connected through the GitHub App. When a task matches, Indent pulls in the procedure. - **Memories** — Durable facts Indent records as you work, such as your preferences and how you like results reported, then applies in later sessions. Tell it to remember or forget something directly. See [Getting good results from Indent](/working-with-indent/getting-good-results). ### Indent for knowledge work ## Automate routine work Some work repeats: on a schedule, or every time something lands in a channel. Describe it to Indent once and it handles each occurrence on its own. Point it at a Slack channel and it runs whenever a new message arrives, summarizing customer feedback as it comes in, drafting a first reply, or researching each new signup and posting what it found in the thread. Or give it a schedule, like every weekday at 9am, and it runs on its own and posts the result where you want it, no triggering message needed. You set it up in plain language right from Slack: tell Indent what you want and it configures the trigger, then sends you a link to review or change it. See [Creating automations in Slack](/automating/automations). ## What to hand Indent ### Research a lead or a company Give Indent a company name or a link to a [HubSpot](/connecting/mcp-servers) record. It searches the web, pulls the account's notes and history from your CRM, and hands back a short brief with the people, the timeline, and the open threads worth knowing before your next call. ### Review a document or spreadsheet Attach a file to your message and tell Indent what to check. It reads the spreadsheet or doc, flags inconsistent numbers and broken formatting, fixes what you ask it to, and returns the corrected file for you to download. ### Answer a question about your data Ask in plain language. Indent writes the query for you, runs it against your [connected database](/connecting/databases), and returns the numbers as a table, a chart, or a downloadable file, without you touching SQL. ### Turn customer feedback into next steps Point Indent at a Slack channel or a doc full of responses. It reads through them, groups the recurring themes, calls out what's urgent, and drafts a summary that says which team should pick up each item. ### Draft a first version Hand Indent the context and let it write the first pass: a reply to a customer, a summary of a meeting, or a project update in [Notion or Linear](/connecting/mcp-servers). You review and refine instead of starting from a blank page. ## Work with your whole team Organization-visible sessions are multiplayer. Teammates can jump in and work alongside you with full context, and Indent knows who's on your team. See [Multiplayer sessions](/collaborating/multiplayer). ## Where you work - **Slack** — Mention `@indent` in a channel, or send a direct message. If Indent isn't in the channel yet, invite it with `/invite Indent`. - **Web app** — Work more closely with Indent to visualize data, fine-tune a report, or watch what it's doing in its browser. From a Slack session, Indent links back to the session on the web, where you can browse every past session. ## Connect your tools Indent works with the tools your team already uses, including Slack, databases, Notion, Linear, and HubSpot. Open [**Integrations**](https://app.indent.com/integrations) to connect them. Each integration's page shows its available scopes. See [Connecting MCP servers](/connecting/mcp-servers). ## Indent remembers As you work, Indent records durable facts, such as your preferences, your team's conventions, and how you like results reported, then applies them in later sessions. Ask it to remember or drop something directly. See [Memories](/learning/memory). # Administration > Manage members, billing, and how Indent accesses your data. Source: https://docs.indent.com/administration/ · Markdown: https://docs.indent.com/administration/index.md Manage members, billing, and how Indent accesses your data. - **Organization defaults** — Set the environment and model used when a new session does not make an explicit selection. - **Users and organizations** — See who's in your organization, manage roles, and set up automatic joining by email domain. - **Billing settings** — Manage your plan, credits, usage, payment method, and invoices. - **Permissions and data** — What Indent can access, how database access and secrets are handled, and who can see a session. # Billing settings > Manage your plan, credits, usage, payment method, and invoices. Source: https://docs.indent.com/administration/billing/ · Markdown: https://docs.indent.com/administration/billing/index.md Manage billing from [**Settings → Billing**](https://app.indent.com/settings/billing). Billing is available to organization admins. ## Plan and credits The page shows your available credit balance. Trial and Team plans have a plan badge; pay-as-you-go does not. Indent draws down credits as it works. ## Usage **Recent usage** charts daily credit use for the selected UTC calendar month. Use the month controls to view the current month or any of the previous three months. Background work Indent starts for itself counts toward the activity that started it. For example, a pull-request review includes the cost of its delegated work. ## Add credits Buy credits with a preset or custom amount from $5 to $10,000. Buying credits requires a payment method. ## Automatic reloads Turn on **Automatic reloads** to top up before you run out. Set **When balance drops below** from $1 to $10,000 and **Add this amount** from $5 to $10,000. The reload amount must be larger than the threshold. The defaults are $10 and $50. Reloads need a card on file and pause if that card is removed. ## Spend limit **Spend limit** caps total usage across your organization for the billing cycle. Turn it on and set a **Monthly budget**; the field starts at $1,000 and the minimum is $1. The section shows how much of the limit the cycle has used. The limit applies to everyone in the organization. Once usage reaches it, Indent stops starting or continuing work, including replies in existing sessions. It also posts a note on any pull request it was about to review, linking back to this page. Raise or clear the limit to resume. ## Payment method Add or update your card through Stripe's secure checkout. Your organization keeps one payment method at a time. ## Invoices View each invoice's billing-cycle summary, daily usage, succeeded payments, and failed payments. Invoices are view-only. If an automatic reload fails, retry it from **Automatic reloads** on the billing page. # Users and organizations > See who's in your organization, invite teammates, manage roles, and set up automatic joining by email domain. Source: https://docs.indent.com/administration/members/ · Markdown: https://docs.indent.com/administration/members/index.md Everyone in your organization appears at [**Settings → Members**](https://app.indent.com/settings/members). Any member can view the list; only admins can invite people, change roles, remove members, or configure joining. ## Roles Each member is either an **Admin** or a **Member**. Admins can manage members, integrations, and billing. ## Invite a teammate Select **Invite user**, enter a work email address, and select **Send invite**. Indent emails them a link to join your organization as a Member. ![The members list with a pending invitation and the Invite user row](/images/members-invite.png) Admins see pending invitations in the members list, each with a **Revoke invite** action; there is no resend, so revoke and invite again. You can't send an invite to an address that's already a member of your organization, an address that has a pending invitation, or to a personal email domain. Use a work address instead. ## Automatic joining Turn on **auto-join** so that anyone who signs up with your organization's verified email domain can join without an invitation. Auto-join needs a verified domain, so it isn't available to a personal organization. ## Manage members Admins can: - **Invite a user** — send an email invitation, and revoke it while it's still pending. - **Change a role** — switch a member between Admin and Member. - **Remove a member** — revoke their access immediately. Admins cannot change their own role or remove themselves from the Members page. # Organization defaults > Set the environment and model used when a new session does not make an explicit selection. Source: https://docs.indent.com/administration/organization-defaults/ · Markdown: https://docs.indent.com/administration/organization-defaults/index.md Organization admins can set the default environment and model from separate Settings pages. Defaults apply when Indent creates a session without a more specific selection. ## Default environment Open [**Settings → Environments**](https://app.indent.com/settings/environments) and use **Default environment** to choose a published environment for: - sessions created in the web app when the composer does not select another environment; - Slack sessions without a channel automation environment; - cron automation runs without an automation environment; - pull request reviews for repositories without a review environment; - sessions started from shared organization integration surfaces when the surface does not select an environment. A selection made in the web composer or on an automation takes precedence over the organization default. Select **No default** to clear the fallback. Without an applicable environment, Indent starts the session without an environment. The web composer remembers a person's last selection and selects the first available environment when there is no organization default. To start without an environment from the web app, explicitly clear the environment in the composer. See [Setting up environments](/getting-started/environments) to create and publish an environment. ## Default model Open [**Settings → Models**](https://app.indent.com/settings/organization-defaults) and choose the model family used for a new session when the session or automation does not select a specific model. A specific model selected in the composer or on an automation takes precedence. The selector lists each family and the model it currently uses, such as **Sonnet 5.5** for **Sonnet**. # Permissions and data > What Indent can access, how database access and secrets are handled, and who can see a session. Source: https://docs.indent.com/administration/permissions-and-data/ · Markdown: https://docs.indent.com/administration/permissions-and-data/index.md Indent works with your systems the way a teammate does: only through the tools you connect, with the access you grant. ## What Indent can access Indent can only use integrations your organization or you have connected — GitHub, Slack, databases, and MCP servers such as Notion, Linear, HubSpot, Datadog, and Sentry. Nothing is reachable until it's connected, and Indent acts within the access that connection grants. To add or remove access, manage the connection from [**Integrations**](https://app.indent.com/integrations). See [Connecting MCP servers](/connecting/mcp-servers). ## Database permissions PostgreSQL queries run in read-only transactions. ClickHouse connections apply or require read-only mode. BigQuery runs SQL with the connected service account's IAM permissions, so use a read-only service account to prevent changes to source data. See [Connecting your database](/connecting/databases). ## Secrets are provided through the app When a task needs a secret, such as an API key or database password, provide it through the app. Saved values are masked after you enter them. Build variables are available to the image build, and runtime variables are injected into the computer's shell and background processes. Commands and programs running there can read those values. See [Setting up environments](/getting-started/environments). ## Organization and personal scope Every integration connects at one of two scopes: - **Organization** — the connection is shared with your team, and anyone in the organization can use it. - **Personal** — the connection is owned by you, and only you can use it. Each integration's page shows the scopes it supports. Database connections, GitHub App installations, and the Slack workspace app are organization-scoped. GitHub and Slack also offer personal account connections. Teammates can see whether you have connected a personal account, but they cannot use it. Using a personal integration's tools requires a private session. A connected personal GitHub account can also author a pull request you request in any session where you participate. See [Private sessions](/collaborating/personal-and-private). ## Who can see a session By default, a session is visible to everyone in your organization, so teammates can follow the work and pick it up. If you created the session, open the share control in the session header to make it private. > **Caution** > > Making a session private is permanent. You can't make it organization-visible again. Direct messages with Indent in Slack and any session on your computer in the [desktop app](/working-locally/desktop) are always private. Slack channel threads stay visible to your organization. # Automating your work > Hand off recurring work so Indent runs it on its own. Source: https://docs.indent.com/automating/ · Markdown: https://docs.indent.com/automating/index.md Hand off recurring work so Indent runs it on its own. - **Creating automations in Slack** — Attach a standing instruction to a Slack channel or a schedule, and Indent runs it on its own. # Creating automations in Slack > Attach a standing instruction to a Slack channel or a schedule, and Indent runs it on its own: on each new message, or at the times you set. Source: https://docs.indent.com/automating/automations/ · Markdown: https://docs.indent.com/automating/automations/index.md Use an automation for a task you repeat often with a clear trigger and a clear result: triaging an alert, drafting a first reply, researching a new signup, or posting a daily summary. An automation runs a standing instruction on its own, either each time a message lands in a Slack channel or on a schedule you set, and replies when there's something to say. ## Create an automation The simplest way is to ask Indent. Mention `@indent` in a channel and describe what you want automated, including a schedule if you want one: ``` @indent set up an automation that researches each new signup posted here, looks up the person and their company, and replies in the thread. Ignore test signups. ``` Indent configures the trigger, pins it to the right environment, and sends you a link to review or change it. `@indent /automate` starts the same thing from the channel you want the automation in: ``` @indent /automate Research each new signup posted in this channel. Look up the person and their company and reply in the thread. Ignore test and placeholder signups. ``` Indent opens a session, works out with you what the job needs to do, and tries the job once before saving it. Both commands work in a channel rather than a direct message. A channel can have one automation that runs on its messages at a time. To change what a channel does, edit its automation rather than creating a second one. You can also create and manage automations in the web app under [**Automations**](https://app.indent.com/automations). To turn a channel's automation off, post `@indent /no-automate` and nothing else. You can re-enable the automation to start it later. ## Choose which messages trigger a run A message-triggered automation reads as a sentence: **When** _a bot posts_ **in** _#channel_. Change the sender to control what starts a run: - **a bot posts** — another tool's messages, such as an alert feed. This is the default. - **a person posts** — messages from your teammates. - **a bot or person posts** — every new message in the channel. - **@indent is tagged** — no run starts on its own. Indent applies the instruction when someone mentions it in the channel. Only top-level messages start a run. A reply inside a thread doesn't, unless it mentions `@indent`. ## How a run works Each automation run gets its own organization-visible session and computer. For a message-triggered automation, Indent replies in a thread on the message that triggered it; for a scheduled one, it posts a short notice in the channel you chose, under the automation's name and its own clock icon, and works in a thread on that notice. Mention `@indent` in that thread to steer the run or ask a follow-up. Watch runs arrive on the automation's **Sessions** tab in the web app, and open any one of them to read it step by step. A session started by an automation shows the automation's name in its header. Everyone in your organization can open these sessions. Choosing **Indent only** suppresses the Slack post, not the session or its outputs. Automation runs use organization-scoped integrations. Connect every service the automation needs for the organization rather than relying on a personal connection. To ask Indent something yourself, mention `@indent` in the channel. Indent answers in a normal session and can use the automation's instruction as context. An automation uses its selected environment when one is set. Otherwise, it uses your organization's default environment. If neither is set, it runs in a sandbox with no code checked out. To run it in the context of your repository, services, and dependencies, point the automation at one of your [development environments](/getting-started/environments). ## Choose a model Choose **Model** while creating an automation or from its **Settings** tab. Use your organization's default model or pin every run to a supported model. You can also ask Indent to set, change, or clear the selection. ## Track usage Open an automation's **Usage** tab to see its month-to-date cost. The reporting period uses UTC month boundaries. The tab shows: - total month-to-date cost and a daily cost chart; - the number of billed runs and average cost per run, where each run is one top-level automation session and includes delegated subagent costs; and - the highest-cost sessions, most expensive first, with each session's time and cost. Select a row to open that session. Any member of your organization who can open the automation can view this usage. If the automation has no billed usage for the month, the tab shows an empty state. ## Values a run reports Automations can record values across every run. These values are visible in the automation's **Sessions** tab. - Track up to five values per automation. - Values may be numbers, text, or links. - Add, change, or remove tracked values by talking to Indent. - All values are optional and will be reported as empty for any run that doesn't report them. ## Memory across runs An automation retains its own memory across every run. Indent records durable notes such as a recurring step, what to skip, or how you want results reported, and reads them on the next run. Ask Indent in the channel to remember or drop something. See [Memories](/learning/memory). ## Change what an automation does Edit the automation in the web app, or ask Indent in the channel. For example, tell it to stop replying to staging deploys. The change applies to every future run. ## Run on a schedule An automation can run on a schedule instead of waiting for a message. Set one up by asking Indent in Slack ("every weekday at 9am, summarize yesterday's signups here"), or in the web app under **Automations**. A scheduled automation needs: - **A frequency** — hourly, daily, weekly, or custom. Daily and weekly run at an hour you pick; custom takes a cron expression such as `0 9 * * 1-5` (every weekday at 9:00). - **A timezone**, which the schedule is evaluated in. - **Where the result goes** — a Slack channel, or **Indent only**. An Indent-only run posts nothing in Slack and remains visible to the organization on the automation's **Sessions** tab. Missed times aren't backfilled. If a scheduled run comes due while the automation is disabled, it runs at the next scheduled time. ## Examples - **Alert triage** — `@indent /automate Triage each Datadog alert posted in this channel. Verify the root cause from the trace and production data, then reply with only the cause, in three sentences or fewer.` - **Security review** — `@indent /automate When a message is posted here, review everything shipped in the last 24 hours using subagents and flag security issues, ranked by severity.` - **Error triage** — `@indent /automate When triggered, pull the day's Sentry issues, surface the top ten, and link each one to the code that caused it and any related Linear ticket.` # Changelog > What's new in Indent, most recent first. Source: https://docs.indent.com/changelog/ · Markdown: https://docs.indent.com/changelog/index.md What's new in Indent, most recent first. ## August 3–9, 2026 ### Publish reports You can now ask Indent to [publish a report](/working-with-indent/reports) when the result of an automation or session needs a durable document. Reports have their own section in the app, and you can leave feedback by selecting text within a report. In Slack, reports are shared as a Slack canvas. Existing Slack connections must reconnect to grant canvas access. ![The Reports browser with search, visibility filters, and recently published reports](/images/changelog/reports-browser.png) ### Control which branches get automatic reviews Under [**Settings → Code Review**](/working-with-indent/reviewing-pull-requests), you can now limit automatic reviews to pull requests targeting the default branch. You can also add source branch patterns that Indent should skip. Explicitly request a review by tagging `@indent` to override these rules. ![Code Review settings with Default branch only enabled and a source branch filter for Dependabot](/images/changelog/code-review-branch-controls.png) ### Set organization defaults Organization admins can now choose a [default environment and model](/administration/organization-defaults) under **Settings → Organization Defaults**. New sessions use these defaults when no environment or model was selected explicitly. ![Organization Defaults with selectors for the default environment and model](/images/changelog/organization-defaults.png) ### See automation usage Each [automation](/automating/automations#track-usage) now has a **Usage** tab with month-to-date spend, a daily cost chart, the average cost per run, and its most expensive sessions. ![An automation's Usage tab with month-to-date spend, a daily chart, and top sessions by cost](/images/changelog/automation-usage.png) ### Improvements - The Review tab is now available to every viewer in a session. It shows working changes and pull request changes side by side without leaving the session. - The desktop app now shows Browser and Processes tabs for cloud sessions. - You can ask Indent to use a specific supported model for an automation. Automations default to the organization or platform default model. - Automation runs can be titled according to standing guidance, such as copying an alert name and dropping timestamps or IDs. - Reports load more results as you scroll, keep filters while you navigate, and show which session published each version. - Settings now has mobile navigation. ### Fixes - Report ZIP exports bypass stale browser caches, and invalid or blank report IDs produce a clear error. - Slack report links show the report title and link back to the report in Indent. - The Review file tree keeps long directory names readable and no longer resets while a session writes files. - The environment setup page no longer reports an absent build as still building. - Empty thinking and assistant rows no longer appear in session transcripts. ## July 27–August 2, 2026 ### Hand a Linear issue to Indent You can now delegate a [Linear](/connecting/linear) issue to Indent, name it in an issue description, or @-mention it in a comment, and Indent opens a session and works the ticket from inside Linear, attributing the work to the ticket's owner. Indent reports its work back to Linear and can ask for clarifications with a link back to answer in Indent. To get started using Indent from Linear, connect Linear at organization scope from [**Linear in Integrations**](https://app.indent.com/integrations/linear). ![A Linear issue delegated to Indent, with the run's thread and an Indent session attachment](/images/changelog/linear-issue.png) ### Autofix on every code review When [code review](/working-with-indent/reviewing-pull-requests) finds an issue that it can immediately fix, the review comment now carries an Autofix link on the finding itself, a link per failing check, and an **Autofix All** link that batches them. ![A review comment with an Autofix link on the finding and an Autofix All Issues link](/images/changelog/autofix-review.png) ### Set up an automation from Slack, and see what every run returned Ask for an [automation](/automating/automations) from inside the Slack channel you want it in, with `@indent /automate draft the weekly changelog`, and Indent opens a session that works the job out with you instead of saving your one-line description as the whole instruction. Indent runs the task once end to end before saving the automation. An automation can also report back from each run. Ask it to track a few values, such as a count, a status, or a link, and they become columns on the automation's **Sessions** tab, one row per run, updating live as runs start and finish. ![The Sessions tab of an automation, with columns for the values each run reported](/images/changelog/automation-run-values.png) ### Archive a session Sessions you're done with can be [archived](/working-with-indent/archiving-sessions) from the home page, the sidebar, or the session itself. Archiving stops a session that's still working, takes it out of your lists, and keeps everything: the link still opens it, and you can unarchive it from the Archive tab on Home. The same menu now carries **Copy link** and **Open in web** / **Open in desktop app**, so moving a session between the browser and the desktop app is one click. ![The session menu, with Archive, Open in desktop app, and Copy link](/images/changelog/session-menu.png) ### Improvements - Pull request reviews are more efficient, with better handling of force-pushes, replies, and additional commits. @-mentioning Indent on a pull request it has never touched will now start a review. - Admins can invite teammates from [**Settings → Members**](/administration/members). - Questions Indent asks in a session are now part of the transcript: you can review questions and answers, and reopen the answer panel if you dismissed it. - Better support for long pasted snippets and long messages in the session view. - Queued messages can be expanded. - Memory shows the path of the file you're reading. - The Code Review page opens with a repository already selected, and the selection lives in the URL so the view is shareable. - Each session in the sidebar shows how long ago it was active. - Streamlined home page display of sessions. - Better mobile navigation. - Existing connections are visible and marked as configured in the catalog, instead of disappearing. - Skill steps in the transcript show the skill's name and expand to its instructions. - Better connections for LaunchDarkly, MotherDuck, and Ramp. - [Datadog](/connecting/datadog) connections can now create and update dashboards (reconnect to update your existing connection). - Better instructions for connection forms. - Indent now surfaces [missing permissions](/connecting/mcp-servers) in existing connections. - Better loading and rendering for Terminal, Browser and Processes panels. ### Fixes - Mentioning Indent in a Slack thread reply that is also sent to the channel now works. - Indent no longer reads its own Slack replies back. - Slack @-mentions show as user names instead of user IDs. - Long command output is no longer silently truncated. - Fixes for Indent's code search. - Commands killed by the system are reported as killed, so Indent can correctly identify out of memory errors. - Oversized tool results and screenshots can no longer wedge sessions permanently. - A memory spike in one process on a sandbox no longer takes down everything else running on it. - Fixes for stalled sessions. - Any session may now be archived. - Automations check their environment when they are saved. - Subagents no longer rename sessions. ## July 20–26, 2026 ### Automations can now run on a schedule [Automations](/automating/automations) are no longer limited to watching a Slack channel. You can now give one a schedule, every day, every week, or any cron expression you like, pick the timezone it runs in, and choose whether the result gets posted to a Slack channel or kept inside Indent. Scheduled automations are available to every organization, and each run shows up in the automation's **Sessions** tab. ![Setting a weekly schedule and timezone on an automation](/images/changelog/automations-schedule.png) The automations screen was rebuilt around this: a searchable list that shows each automation's trigger at a glance, a dedicated editor for the standing instructions Indent follows on every run, and per-automation memory. ![The automations list, showing a scheduled automation and a Slack-triggered one](/images/changelog/automations-list.png) When a scheduled automation starts, Indent posts a short notice in Slack under the automation's own name, with its own clock avatar so different schedules are easy to tell apart. The run's replies land in that thread, and mentioning Indent there continues the same run instead of starting a new session. Channel automations also got finer control over what they react to: a bot posting, a person posting, either, or only messages that tag Indent. You can also ask Indent in a session to list, create or change your automations instead of filling in the form yourself. ### Spending controls for code review [Code Review](/working-with-indent/reviewing-pull-requests) settings now take a maximum cost per pull request, per repository. When a pull request reaches the ceiling, Indent stops reviewing new pushes and posts a notice explaining that the review is paused. You can authorize one more round from the link in that notice or by replying to Indent on the pull request, and that round reviews the current head commit with current CI results rather than a stale snapshot. Leaving the field blank keeps reviews unlimited, which is what existing repositories get. Reviews now also pause when billing blocks them, either out of credit or at an organization spending limit, with a comment saying so and a link to billing. ### Choose how often Indent reviews a pull request Each repository can now be set to review every push (the existing behavior) or only the first time a pull request opens. In first-review-only mode Indent posts its first review and then leaves the pull request alone. Later pushes, CI runs, comments and labels don't start another round, and the review comment carries a link to request one when you want it. Review comments also say what triggered each round and which commit was reviewed. ### Organization-wide spending limit Billing settings now include a monthly spending limit for the whole organization: admins can set it, change it, or clear it, and work stops for everyone once it is reached. The pre-filled default is $1,000 (was $100), and the older per-user caps are gone in favor of this single control. Automatic credit reloads now trigger when your balance drops below $10 rather than $5. Saved values are untouched. The daily usage chart separates spend into automations, pull request reviews and sessions, with a total per day in the tooltip. Spend from nested background work is now attributed to the activity that started it, so a review or an automation shows its true cost instead of leaking into the general sessions bucket. ### A home page for everything in flight Indent now opens onto a live home page listing every session you and your team have going, with search, Sessions / Team / Archive tabs, and private-only and local/cloud filters. The filters live in the URL, so a view is shareable and the back button works. Each row shows status, participants, elapsed time, the Slack channel a session came from, and a hover summary of the pull requests it opened or merged. A composer on the page starts a new session without leaving it. ### Setup for people joining an organization that already exists Someone invited into an organization that is already configured now gets a short setup flow of their own, connect GitHub and then connect Slack, instead of being dropped straight into the app or re-running the whole organization setup. Anyone already using Indent is unaffected. ### A new default model New sessions everywhere, in the app, Slack, GitHub and code review, now default to Claude Opus 5. ### Documentation site Documentation moved to a new home at [docs.indent.com](https://docs.indent.com), with sidebar navigation, per-page contents, full-text search, and a plain-Markdown version of every page for agents to read. Product content is still thin: this week shipped the site itself plus an overview and a placeholder quick start. ### Improvements - When Indent asks you a multiple-choice question, picking an option submits it instead of waiting for a separate send, and its replies stream in as they are written rather than landing all at once. - Standing instructions for an automation can be about twice as long as before, and instruction and memory previews render as formatted text instead of raw markup. - The desktop app has its own settings page showing the installed version and update controls, Cmd+N opens a new session, and `indent://` links and the session menu open sessions directly in the app. - Browser access from the desktop app now runs over Chrome's own extension channel, with a card in desktop settings telling you whether the browser is connected. You grant or revoke control of a single window from the extension icon, and controlled tabs sit in their own Indent tab group. - Environments: you can trigger a verification run from the setup screen, and a machine boots automatically if none is running. The Verify step only appears once there is something to verify and stays disabled until a build has succeeded. - Light/dark theme now has a follow-system option, and it is available from the settings menu. - New integrations: Grafana Cloud, Plain and Vanta. Editing a connected server is now an explicit edit mode over a single draft, covering sign-in method, address and credentials, with Test connection, Cancel and Save changes, and admins can delete a custom server definition outright rather than only disconnecting it. Indent also keeps a synced snapshot of each server's tools, so tool lists load instantly and a slow server no longer hides them. - Indent now reads the skill files checked into your connected repositories and keeps them current in the background, so a session knows a repository's skills without scanning the checkout. - The built-in terminal's colors were retuned to match the app instead of pure black. - When an MCP server fails, Indent tells you what the server actually returned instead of a generic failure. - Markdown files in the file sidebar render formatted by default with a toggle for the raw source, memory files link to each other so you can browse them like a small wiki, and the memory you are viewing is part of the URL. - Replying in an Indent Slack thread without @-mentioning gets a one-time nudge, so a message that Indent will not see does not just sit there. Slack messages from people without an Indent account are held and released once they sign in, and organizations with domain auto-join get accounts created for Slack senders automatically. - On GitHub, Indent no longer treats every comment as something it must answer, only ones that @-mention it. - CI status updates sent into a session now list only the failed checks. ### Fixes - Bash command output stays visible while a command runs and is replaced by the saved output when it finishes, instead of sticking on "Running…". - A review's working notes now carry forward across pushes instead of restarting from scratch on every commit. - Replying inline to one of Indent's review comments works again without re-mentioning it. - Indent reliably ends its turn after sending a final reply instead of carrying on working. - A tool result Indent could no longer parse used to make the session unusable; it now recovers. - Stopping a session now actually stops the command running on the computer. - A local computer whose credential expired now refreshes it instead of reconnecting forever. - Sessions resume correctly after an interrupted response instead of stalling. - Long activity labels no longer overflow the live activity row. - Model errors coming from the upstream provider are now explained in plain language. - Fixed an off-by-one in payment retry scheduling that could delay a retried charge. - One broken integration connection no longer breaks the whole integrations, repositories and environments page. It shows as an "Unavailable" row you can open and remove. - The sidebar session list is no longer hidden on the home page, and home status icons match the sidebar's for the same state. - Replies from the web app are no longer dropped on a freshly created session. - Uploaded images render again in the transcript. - A published environment no longer shows an empty list of verification goals and repositories. - The desktop "Update required", error and not-found screens can be dragged by the top bar again. # Cloud sessions > Use the browser and background services running inside a cloud session's sandbox. Source: https://docs.indent.com/cloud-sessions/ · Markdown: https://docs.indent.com/cloud-sessions/index.md A cloud session runs in an isolated sandbox. You can work with the sandbox directly from the session's tool panel. Cloud sessions behave the same in the web and desktop apps. Opening one in the desktop app keeps [**Browser**](/cloud-sessions/browser), [**Processes**](/cloud-sessions/processes), and [**Terminal**](/working-locally/terminal) connected to the cloud sandbox. - **Browser** — Open and control the browser running inside the sandbox. - **Processes** — Watch and manage the services started by the session's environment. - **Terminal** — Open a shell in the sandbox and work alongside Indent. # Browser > Open and control the browser running inside a cloud session's sandbox. Source: https://docs.indent.com/cloud-sessions/browser/ · Markdown: https://docs.indent.com/cloud-sessions/browser/index.md Every cloud session includes a browser inside its sandbox. Indent can use it to test your application, and you can open the same browser from the session's **Browser** tab. ![The Browser tab showing a local application running in the session's sandbox](/images/browser-panel.png) ## Open the browser Select **Browser** in the tool panel toolbar at the top of the session. Opening the tab wakes a sleeping sandbox. The panel connects automatically and waits for the first browser frame. Click inside the browser to interact with it. You can navigate, type, scroll, and use browser devtools as you would in a local browser. While the browser has keyboard focus, click outside it to use Indent's keyboard shortcuts again. Use the panel controls to expand, restore, close, or resize the tool panel. The browser viewport resizes with the panel. If the connection drops, the panel reconnects automatically. If an application opens more than one top-level window, the Browser tab displays the windows in a grid. ## Open your application at session start An environment can automatically open up to 16 URLs when a session starts. In [**Settings → Environments**](https://app.indent.com/settings/environments), select an environment, open **Configure**, and add the URLs under **Browser tabs**. Use a loopback URL such as `http://localhost:3000` for a service running in the sandbox. Indent waits for configured loopback services before opening the browser. Publish the pending environment revision after editing. The URLs apply when a sandbox boots cold from that revision; running or resumed sandboxes keep their existing browser. You can also ask Indent to open a URL, test a flow, or capture a screenshot. Its actions appear in the same browser. # Processes > Watch and manage the services started by a cloud session's environment. Source: https://docs.indent.com/cloud-sessions/processes/ · Markdown: https://docs.indent.com/cloud-sessions/processes/index.md The **Processes** tab shows the long-running services configured by a cloud session's environment. Use it to watch a development server, database, worker, or other service while you work. ![The Processes tab showing live output from services started by the session's environment](/images/processes-panel.png) ## Watch process output Select **Processes** in the tool panel toolbar at the top of the session. Each configured process has its own tab with live output and scrollback. Select a tab to switch services, or drag tabs to reorder them. A green dot means a process is active. Configured commands are supervised. If a command exits or crashes on its own, Indent restarts it one second later. Close a process tab to intentionally stop that process. An intentional stop suppresses its restart for the current session. The process stays in the environment configuration and starts again in future sessions. > **Note** > > The panel shows services configured by the environment. It does not list every operating-system > process, and it cannot start an ad hoc process. Use the [Terminal](/working-locally/terminal) for > other commands. ## Configure processes Open [**Settings → Environments**](https://app.indent.com/settings/environments), select an environment, and open **Configure**. Under **Processes**, add a unique name and the command to run. For example: | Name | Command | | ----- | --------------------------------------------- | | `web` | `cd /workspace/acme/app && pnpm dev` | | `api` | `cd /workspace/acme/app && pnpm dev:api` | | `db` | `cd /workspace/acme/app && docker compose up` | Processes start in `/workspace` when a session begins. Include `cd /workspace//` in commands that run inside a repository. Publish the pending environment revision after editing. The changes apply to new sandboxes launched from that revision and do not require an image rebuild. If no services are configured, the tab shows **No processes running**. # Adding Indent to your team > Bring Indent into how your team works — in Slack, in Linear, in shared sessions, and with control over what stays private. Source: https://docs.indent.com/collaborating/ · Markdown: https://docs.indent.com/collaborating/index.md Bring Indent into how your team works — in Slack, in Linear, in shared sessions, and with control over what stays private. - **Working with Indent in Slack** — Hand Indent a task from a Slack channel or direct message, and pick the work back up in the web app. - **Working with Indent in Linear** — Delegate a Linear issue to Indent or mention it on one, and follow the work from the issue. - **Multiplayer sessions** — Every session is shared, so teammates can jump in and work alongside you and Indent. - **Personal integrations and private sessions** — Keep a session to yourself, and connect supported integrations with your personal accounts. # Multiplayer sessions > Every session is shared, so teammates can jump in and work alongside you and Indent. Source: https://docs.indent.com/collaborating/multiplayer/ · Markdown: https://docs.indent.com/collaborating/multiplayer/index.md A session isn't a private thread between you and Indent — it's a shared workspace teammates can step into and work in alongside you. Indent knows who's on your team. Wherever you tag it, it joins with the full context of the task, so a teammate who jumps in doesn't have to catch it up. ## Join from web, Slack, or GitHub - **Web** — Open a session at [app.indent.com](https://app.indent.com) and a teammate can view it and add messages. Everyone sees the same history and the same live work. - **Slack** — Anyone in a channel can mention `@indent` in the same thread and take part. The thread is the session; each person's messages land in the shared context. See [Working with Indent in Slack](/collaborating/working-in-slack). - **GitHub** — A pull-request review is a session too. Anyone can reply in the comments to steer the work, and Indent responds with the full history of the review. See [Reviewing pull requests](/working-with-indent/reviewing-pull-requests). > **Note** > > Private sessions are the exception: a direct message with Indent, a desktop local session, or a > session you've made private stays with you. See [Personal integrations and private > sessions](/collaborating/personal-and-private). # Personal integrations and private sessions > Keep a session to yourself, and connect supported integrations with your personal accounts. Source: https://docs.indent.com/collaborating/personal-and-private/ · Markdown: https://docs.indent.com/collaborating/personal-and-private/index.md A private session is visible only to you; by default, sessions are visible to everyone in your organization. Personal integrations rely on private sessions, so the two work together. ## Make a session private If you created the session, open the share control in the session header and make the session private. Only you can see it afterward. > **Caution** > > Making a session private is permanent. Anyone viewing it loses access, and you can't make it > organization-visible again. Some sessions are private automatically: - A direct message with Indent in Slack. - Any session that runs on your computer in the [desktop app](/working-locally/desktop). Slack channel threads stay visible to your organization. ## Organization and personal integrations Every integration connects at one of two scopes: - **Organization** — the connection is shared with your team, and anyone in the organization can use it. - **Personal** — the connection is owned by you, and only you can use it. Personal scope is available only for integrations that support it. Database connections, GitHub App installations, and the Slack workspace app are organization-scoped. GitHub and Slack also offer personal account connections. Teammates can see whether you have connected a personal account, but they cannot use it. ## Connect a personal integration Open [**Integrations**](https://app.indent.com/integrations), select the integration, and select its personal connection option. You authorize it with your own account, and Indent acts with your access instead of the team's. ## Use a personal integration in a session Open the integrations picker in a session. It has three tabs: **All**, **Shared**, and **Personal**. Personal integration tools work only in private sessions. If the session is organization-visible, selecting one asks you to make the session private. Confirm the change, then select the integration. A connected personal GitHub account is also used to author pull requests you request in any session where you participate. For how scope and visibility affect what Indent can reach, see [Permissions and data](/administration/permissions-and-data). # Working with Indent in Linear > Delegate a Linear issue to Indent or mention it on one, and follow the work from the issue. Source: https://docs.indent.com/collaborating/working-in-linear/ · Markdown: https://docs.indent.com/collaborating/working-in-linear/index.md Once Linear is connected at organization scope, you can put Indent on an issue and follow what it does without leaving Linear. To connect the integration first, see [Connecting Linear](/connecting/linear). ## Delegate an issue to Indent There are three ways to start Indent from an issue: - **Delegate the issue to Indent.** Indent owns the issue and implements it. - **@-mention Indent in the issue description.** Indent answers what the description asks, and implements only if you ask it to. - **@-mention Indent in a comment.** Indent answers in that thread, and implements only if you ask it to. Delegation and assignment are separate fields in Linear, so delegating to Indent leaves the issue's assignee alone. To keep going, reply in the thread Linear opened. Every reply there reaches Indent, so you don't need to mention it again. ## What Indent reads Indent gets the issue's identifier, title, URL, description, and assignee, plus the comments in the thread it was mentioned in. A new mention on the same issue adds the comments posted since the last turn. A reply in a thread Indent is already working in carries only that reply. It doesn't read the issue's labels, status, project, cycle, parent or sub-issues, other comment threads, or files attached to the issue. Ask for anything else in your request. The Linear tools are available from the first turn of the session, so Indent can also look it up. ## One session per issue Indent keeps one session per issue. A second delegation or mention on the same issue continues that session, and Indent picks up from what it has already done. Each Linear thread is answered on its own. Two requests on the same issue run one after the other. The session is titled with the issue identifier, such as `ENG-231: Rate-limit the export endpoint`, and is visible to your organization. ## Follow the work Linear opens a thread for each delegation or mention, and Indent posts its progress there as it works. Progress updates arrive as thoughts, and the last message of a turn is the response. A turn that fails ends with an error in the thread instead. - Each thread has an **Open in Indent** link, and the issue gets an **Indent session** attachment. - A pull request Indent opens is linked on the thread, and attached to the issue when the issue is delegated. - On a delegated issue, Indent's answer also lands as a comment on the issue. - Images render inline. Other files are attached as links. A file over 25 MiB links to the session in Indent instead. - If Indent has a question for you, it posts a link to answer it in Indent. Commenting in Linear instead dismisses the question and steers the run. On a delegated issue, Indent opens pull requests as the issue's assignee, falling back to whoever delegated the issue. The assignee needs an Indent account for that. To stop a run, use Linear's **Send stop request**. Indent replies that it was stopped before it finished. ## Teammates who don't have an Indent account Indent matches whoever delegates or mentions it by their Linear email address. If your organization signs people up automatically by email domain, a teammate gets an account there and then. Without a match, Indent replies in the thread and the run doesn't start. A Linear email that matches no Indent account gets a link to sign up. One that matches several accounts gets asked to link their Linear account in Indent. ## Limits Indent doesn't change an issue's status, assignee, or labels on its own. Ask for it in your request. A tool call that needs your approval isn't shown in Linear. The run waits until you approve it in Indent, so open the session from the thread if a run goes quiet. Delegating or mentioning Indent from a Linear project or document does nothing. Use an issue. # Working with Indent in Slack > Hand Indent a task from a Slack channel or direct message, and pick the work back up in the web app. Source: https://docs.indent.com/collaborating/working-in-slack/ · Markdown: https://docs.indent.com/collaborating/working-in-slack/index.md Once Slack is connected, you work with Indent the way you'd work with a teammate who's in the channel: mention it, hand it a task, and it replies in a thread. To connect your workspace first, see [Connecting Slack](/connecting/slack). ## Mention Indent in a channel In any channel Indent is in, mention `@indent` with your request. Indent replies in a thread on your message and keeps the back-and-forth there, so it stays out of the main channel. If Indent isn't in the channel yet, add it with `/invite Indent`, then mention it. Editing an existing message to add `@indent` counts as a mention. > **Note** > > A Slack channel thread stays visible to your organization. To work privately, direct message > Indent instead. ## Keep talking in the thread Once you've mentioned Indent in a thread, you don't need to mention it again. Reply the way you would to a teammate. Indent reads the messages meant for it and the ones that change the work it's doing, and decides for itself whether to answer. Side conversations between people are left alone. There's no keyword to make Indent skip a message. To be sure it answers, mention `@indent`. Everyone who takes part in the thread is part of the session: the people who post in it, and anyone mentioned in it. Indent can tell who asked for what. ## Direct message Indent Send Indent a direct message to start a one-on-one session. A direct message with Indent is always a private session, visible only to you — good for work you'd rather not put in a shared channel. ## Teammates who don't have an Indent account If your organization signs people up automatically by email domain, a teammate who mentions Indent for the first time gets an account there and then, and Indent answers straight away. Everyone else gets a sign-up prompt, and Indent holds their message. Once they sign in and link their Slack account, Indent picks up what they asked for. ## Move to the web app Slack is the right place to kick something off, but a long or detailed task is easier to follow in the web app, where file edits, query results, and pull requests render inline. When Indent starts a session from Slack, its last message links to that session on [app.indent.com](https://app.indent.com). Open the link to watch the work step by step and keep going there. The session is the same one either way — anything you or a teammate does in Slack or on the web is part of a single, shared session. See [Multiplayer sessions](/collaborating/multiplayer) for how teammates join in. # Connecting your systems > Connect Indent to your code, chat, data, and tools so it can act on your behalf. Source: https://docs.indent.com/connecting/ · Markdown: https://docs.indent.com/connecting/index.md Connect Indent to your code, chat, data, and tools so it can act on your behalf. - **Connecting GitHub** — Connect the GitHub App and your personal account so Indent can work with repositories and collaborate on pull requests. - **Connecting Slack** — Connect your Slack workspace so Indent can work with you in channels, threads, and direct messages. - **Connecting Beeper** — Connect your Beeper Matrix ID so you can start and continue Indent sessions from Beeper. - **Connecting your database** — Connect a database so Indent can inspect schemas, run SQL with the permissions you provide, make charts, and return downloadable results. - **Connecting Linear** — Connect the Linear MCP integration so Indent can work with your issues in a session, and delegate issues to it from inside Linear. - **Connecting Notion** — Connect the Notion MCP integration through a personal account or a service account shared with your organization. - **Connecting Google Drive** — Configure Google's hosted Drive MCP server so Indent can search, read, create, and copy Drive files. - **Connecting MCP servers** — Connect the built-in MCP catalog — Notion, Linear, HubSpot, Datadog, and Sentry — or register a custom server, at organization or personal scope. - **Connecting Datadog** — Connect Datadog so Indent can pull logs, metrics, traces, and monitors during investigations. - **Connecting Sentry** — Connect Sentry so Indent can pull in error reports and stack traces. - **Connecting Tailscale** — Put Indent's computers on your tailnet so sessions can reach services that aren't on the public internet. # Connecting Beeper > Connect your Beeper account so you can start and continue Indent sessions from a direct message or Matrix room. Source: https://docs.indent.com/connecting/beeper/ · Markdown: https://docs.indent.com/connecting/beeper/index.md Indent connects to your Beeper account through Matrix. Each person connects their own Beeper Matrix ID, then messages `@indent:indent.com` from Beeper. ## Connect Beeper 1. **Find your Beeper Matrix ID** In Beeper, open **Settings** and select your name. Copy the ID ending in `:beeper.com`, such as `@alice:beeper.com`. 2. **Connect your Matrix ID to Indent** Open the [Matrix personal integration](https://app.indent.com/settings/integrations/personal/matrix). Enter your Beeper Matrix ID and select **Connect**. 3. **Start a direct message with Indent** In Beeper Desktop or Beeper for Android, start a new chat and search for `@indent:indent.com`. Send your request in the new conversation. Beeper currently supports starting a Matrix direct message on desktop and Android. See [Using Matrix Chats in Beeper](https://help.beeper.com/using-matrix-chats-in-beeper) for Beeper's current platform instructions. Each teammate who wants to message Indent from Beeper must connect their own Beeper Matrix ID to their Indent account. ## Work with Indent in Beeper In a direct message, send a request without mentioning Indent. Reply in the same thread to continue the session. A new top-level message starts another session. Direct-message sessions are private and visible only to you. To work in a shared, invite-only Matrix room, add `@indent:indent.com` as a participant. Mention Indent in a new message to start a session. Replies in that thread continue the same session without another mention. The session is visible to your Indent organization. Indent adds an 👀 reaction while it works and a ✅ reaction when it finishes. React with 🛑 to the first message in the thread to stop the current run. Replies can include files and images. Each reply links to the same session in the Indent web app. ## Continue in the web app Open the session link in Indent to inspect tool calls, file changes, and other work that Beeper does not render inline. You can continue the same session from Beeper or the web app. When Indent needs you to answer a question or approve an action, it posts a link in Beeper. Complete the action in the web app. ## Limits Indent reads text messages from Beeper. Files and images that you send in Beeper are not added to the session. ## Troubleshooting If Indent does not reply: - Confirm that **Settings → Personal integrations → Matrix** shows the same `@username:beeper.com` ID as your Beeper account. - Include the leading `@` when you search for `@indent:indent.com`. - Mention Indent in the first message of a shared room thread. - If Indent asks you to link your Matrix ID, open the link, save the prefilled ID, and send your request again. # Connecting your database > Connect a database so Indent can inspect schemas, run SQL, make charts, and return downloadable results. Source: https://docs.indent.com/connecting/databases/ · Markdown: https://docs.indent.com/connecting/databases/index.md Indent can use a connected database across investigations, analyses, and coding tasks. See [Querying and analyzing data](/working-with-indent/querying-data) for examples. ## Add a database Add a database from [**Databases in Integrations**](https://app.indent.com/integrations?filter=databases). Choose the database type and enter its connection details. Databases are organization-scoped, so the connection is shared with your team. Use credentials that can read only the schemas and tables Indent needs. PostgreSQL transactions and ClickHouse connections also enforce read-only access. BigQuery runs SQL with the service account's IAM permissions, so the account itself must be read-only to prevent writes. Give each database a clear label so it is easy to identify when selecting one in a session. ![The PostgreSQL connection form with fields for the display name, host, port, database, username, and password.](/images/database-connection-form.png) ## Connect to a public endpoint PostgreSQL and ClickHouse connections originate from Indent's cloud environment. The database must therefore have a public hostname or IP address and accept inbound connections on its database port. A private address, such as `localhost`, `10.x.x.x`, `172.16.x.x`–`172.31.x.x`, or `192.168.x.x`, is not reachable. Before connecting: 1. Enable public network access for the database instance. 2. Allow inbound TCP connections on the database port. Keep the network rule limited to that port; do not expose other services. 3. Create a dedicated read-only database user with access only to the schemas and tables Indent should query. 4. Enable TLS on the database. New PostgreSQL connections encrypt traffic without validating the server certificate; to have Indent validate it, set **SSL mode** to **Verify CA** or **Verify full** when you enter the connection details below. Use **HTTPS** for ClickHouse. Its certificate must chain to a publicly trusted certificate authority. Then enter: - **Host:** the public hostname without a protocol, such as `example.abc123.us-west-2.rds.amazonaws.com`. - **Port:** usually `5432` for PostgreSQL. Use the port shown by your provider for ClickHouse. - **Database:** the database Indent should query. - **Username** and **Password:** the dedicated read-only credentials. - **SSL mode (PostgreSQL):** **Require** by default, which encrypts traffic without validating the server certificate. Choose **Verify CA** or **Verify full** to validate it. - **Protocol (ClickHouse):** use **HTTPS** for an encrypted connection. Click **Test connection** to check the settings. Click **Connect** to save the connection. For Amazon RDS, set **Publicly accessible** to **Yes** and add an inbound rule to the instance's security group for its PostgreSQL port. Indent currently connects to PostgreSQL with a database username and password; AWS IAM database authentication is not supported. ### Import a PostgreSQL URL If you already have a connection string, click **Import from URL** above the **Host** field, paste a `postgres://` or `postgresql://` URL, and click **Import values**. Indent fills in host, port, database, username, password, and SSL mode, and leaves the display name alone. > **Note** > > Tailscale on a session's computer does not route connected database queries. For a database that > is available only on your tailnet, use a database client directly on a computer connected to that > tailnet. See [Connecting Tailscale](/connecting/tailscale). ## Supported databases Indent supports **PostgreSQL**, **BigQuery**, and **ClickHouse**. Connection details differ by engine: - **BigQuery:** a service-account JSON key and a location (defaults to US). Use a service account with read-only IAM permissions. - **PostgreSQL:** host, port, database, user, password, and SSL mode. - **ClickHouse:** host, port, database, user, and password over HTTPS. ## Next steps [Querying and analyzing data](/working-with-indent/querying-data) explains how to ask Indent a question about your data. # Connecting Datadog > Connect Datadog so Indent can pull logs, metrics, traces, and monitors during investigations. Source: https://docs.indent.com/connecting/datadog/ · Markdown: https://docs.indent.com/connecting/datadog/index.md Datadog gives Indent live production context, so it can [investigate incidents](/working-with-indent/investigating-incidents) without you copying from another tab. ## Connect Datadog 1. **Open Datadog in Integrations** Open [**Datadog in Integrations**](https://app.indent.com/integrations/mcp%3Adatadog). 2. **Choose a scope** Select **Connect service account** to share the connection with your organization, or **Connect personal account** to use your own Datadog access in private sessions. 3. **Choose your site** Choose your Datadog site: US1, US3, US5, EU1, AP1, or AP2. 4. **Prepare Datadog for OAuth** If you use OAuth, ask a Datadog administrator to open **Organization Settings → Preferences**, add `https://app.indent.com/integrations/callback` under **MCP OAuth Redirect URLs**, and confirm that **MCP Access** is enabled. 5. **Authenticate** Datadog connects through its hosted MCP server, with three options: - **OAuth** — redirects you to Datadog to authorize access. - **Personal or service access token** — uses a token with **mcp_read**, plus **mcp_write** and resource permissions when the tools need them. MCP Access must be enabled, and your role must include MCP Read. - **API and application keys** — uses `DD_API_KEY` and `DD_APPLICATION_KEY`. This option is organization-only. Datadog connects at organization or personal scope, except the API-and-application-keys option, which is organization-only. See [Connecting MCP servers](/connecting/mcp-servers) for how scopes work. # Connecting GitHub > Connect the Indent GitHub App and your personal account so Indent can work with repositories and collaborate on pull requests. Source: https://docs.indent.com/connecting/github/ · Markdown: https://docs.indent.com/connecting/github/index.md GitHub is the backbone of Indent's engineering work. Most coding, review, and incident tasks start from a connected repository. ## Connect GitHub 1. **Connect your personal account** Open [**GitHub in Integrations**](https://app.indent.com/integrations/github%3Aworkspace) and select **Connect personal account** so pull requests you request can be authored by your GitHub user. This connection uses your GitHub access in any session where you participate. 2. **Install the GitHub App** On the same page, select **Install GitHub app**. Sign in to GitHub and install the Indent GitHub App for the organizations and repositories you want Indent to work in. 3. **Set up an environment** Open [**Settings → Repositories**](https://app.indent.com/settings/github-repositories), pick a repository, and select **Setup Environment** to build a [development environment](/getting-started/environments). Indent builds an image from a Dockerfile, clones the repository, and starts your services. The organization GitHub App is shared with your team and grants access to its selected repositories. A personal account connection lets pull requests you request be authored by your GitHub user. Teammates can see that you connected it, but they cannot use it for their requests. ## Manage GitHub [**GitHub in Integrations**](https://app.indent.com/integrations/github%3Aworkspace) shows the organization workspaces and personal accounts connected to Indent. Use a connection's menu to reconnect or disconnect it. [**Settings → Repositories**](https://app.indent.com/settings/github-repositories) lists the repositories available through the GitHub App. Select **Manage GitHub App** to change which repositories the app can access. Each repository shows one of these actions: - **Setup Environment** appears when the repository has no environment. It creates a [development environment](/getting-started/environments) for that repository. - **Manage** appears when one environment exists. A count appears when several exist. The menu opens each environment and includes **Create another environment**. ## What Indent does with GitHub With the app installed, Indent can: - Read and edit files in your repositories. - Clone repositories into a session, and pull in related repositories when work spans more than one service. - Run and test your application in the session. - Open and update pull requests. - Review pull requests, and comment on, label, and react to them. - Track CI checks and commit statuses, and read GitHub Actions workflow runs. The exact permissions Indent requests appear on GitHub's install screen when you add the app. ## Next steps - [Writing code](/working-with-indent/writing-code) explains how to hand Indent a change and get a pull request back. - [Reviewing pull requests](/working-with-indent/reviewing-pull-requests) explains how Indent reviews your team's pull requests. # Connecting Google Drive > Configure Google's hosted Drive MCP server so Indent can search, read, create, and copy Drive files. Source: https://docs.indent.com/connecting/google-drive/ · Markdown: https://docs.indent.com/connecting/google-drive/index.md Google Drive connects through Google's hosted MCP server. Indent can search and read files available to the connected account, create files and folders, and copy existing files. ## Configure Google Cloud 1. **Select a Google Cloud project** Open the [Google Cloud Console](https://console.cloud.google.com/) and select or create the project that owns the OAuth client. 2. **Enable both Drive APIs** Enable the [Google Drive API](https://console.cloud.google.com/apis/library/drive.googleapis.com) (`drive.googleapis.com`) and the [Google Drive MCP API](https://console.cloud.google.com/apis/library/drivemcp.googleapis.com) (`drivemcp.googleapis.com`). The integration requires both services. 3. **Configure the OAuth consent screen** Under **Google Auth Platform**, configure **Branding** and **Audience**. Choose **Internal** when only members of the Google Workspace organization need access. For an **External** app in testing, add every person who will connect under **Audience → Test users**. 4. **Add the Drive scopes** Under **Google Auth Platform → Data Access**, manually add these scopes: - `https://www.googleapis.com/auth/drive.readonly` - `https://www.googleapis.com/auth/drive.file` 5. **Create an OAuth client** Under **Google Auth Platform → Clients**, create a **Web application** client. Add `https://app.indent.com/integrations/callback` as an authorized redirect URI, then copy the client ID and client secret. 6. **Connect Google Drive in Indent** Open [**Google Drive in Integrations**](https://app.indent.com/integrations/mcp%3Agoogle-drive-drivemcp). Select **Connect service account** to share the connection with your organization, or **Connect personal account** to use it in private sessions. Enter the OAuth client credentials, then sign in as the Google account whose Drive access Indent should use. > **Note** > > Reconnect Google Drive after enabling an API or adding a scope. Existing OAuth tokens do not gain > the new access automatically. ## What the scopes allow - `drive.readonly` lets the MCP server view and download files the connected account can access. - `drive.file` lets the MCP server create files and work with files created or opened through the application. It does not grant general write access to every existing file. Google classifies `drive.readonly` as a restricted scope. External OAuth apps must complete Google's verification before people outside the configured test users can connect. ## Write support Google's current Drive MCP server exposes `create_file` and `copy_file` as write operations. It can create Google Docs, Sheets, Slides, folders, and uploaded files. It can also copy an existing file into a folder where the connected account has write access. The server does not currently expose tools to edit an existing file's content, change its sharing, or delete it. Adding the full `https://www.googleapis.com/auth/drive` scope does not add those tools. Use a custom MCP server that implements the required Drive API operations when Indent needs general write access. ## Troubleshooting - Confirm that both `drive.googleapis.com` and `drivemcp.googleapis.com` are enabled in the same project as the OAuth client. - Confirm that the account connecting an External app is listed under **Test users**. - Confirm that the OAuth client is a Web application and the redirect URI matches exactly. - Reconnect the integration after changing APIs, scopes, audience, or OAuth client settings. See [Google's Drive MCP setup guide](https://developers.google.com/workspace/drive/api/guides/configure-mcp-server) and [Drive MCP tool reference](https://developers.google.com/workspace/drive/api/reference/mcp) for the upstream configuration and current tool surface. # Connecting Linear > Connect Linear so Indent can work with your issues in a session, and delegate issues to it from inside Linear. Source: https://docs.indent.com/connecting/linear/ · Markdown: https://docs.indent.com/connecting/linear/index.md Connecting Linear gives Indent your issues and projects as a tool. You can also delegate an issue to Indent from inside Linear and follow the work there. ## Connect Linear 1. **Open the integrations page** Open [**Linear in Integrations**](https://app.indent.com/integrations/linear). 2. **Choose a scope** Select **Install Linear app** to share the integration with your organization and let people delegate issues to Indent. Select **Connect personal account** to connect as yourself in a [private session](/collaborating/personal-and-private). An issue can't be delegated or mentioned to a personal connection. 3. **Authorize with Linear** Linear connects through its hosted MCP server. Authorize access, and Indent can use Linear in your sessions. > **Note** > > An organization-scoped Linear connection acts as an application, not as the person who set it up, > so it needs no service account: Linear attributes Indent's issues and comments to Indent, and the > connection keeps working when that person's account changes. A workspace admin has to approve the > install. A personal connection acts as you and inherits your own Linear access. ## What Indent does with Linear - Reads and searches issues, projects, and their details. - Creates issues from a request in a session. - Updates issues, including status, assignee, and other fields. - Comments on issues. ## Next steps - [Working with Indent in Linear](/collaborating/working-in-linear) — delegate an issue, mention Indent on one, and follow the work from Linear. - [Connecting MCP servers](/connecting/mcp-servers) — the built-in MCP catalog and how scopes work. # Connecting MCP servers > Connect Indent to hundreds of tools from Integrations, or register your own server, at organization or personal scope. Source: https://docs.indent.com/connecting/mcp-servers/ · Markdown: https://docs.indent.com/connecting/mcp-servers/index.md import { McpDirectory } from "@/components/mdx"; An MCP server gives Indent a set of tools it can use during a session. Indent ships a catalog of hundreds of them, so most of the tools your team already uses are a click away. Start with one or two that match your most common workflows, and add more as you go. ## Browse integrations Browse and connect servers from [**Integrations**](https://app.indent.com/integrations). The catalog spans the categories teams reach for most, including issue tracking, docs, CRMs, observability, analytics, and payments: - **Issue tracking and docs** — Linear, Notion. - **Observability** — Datadog, Sentry. - **CRM and support** — HubSpot, Plain. - **Analytics and experimentation** — Amplitude, Statsig. - **Payments** — Stripe, PayPal. A few have dedicated setup pages — [Linear](/connecting/linear), [Notion](/connecting/notion), [Datadog](/connecting/datadog), and [Sentry](/connecting/sentry) — but the rest connect the same way from Integrations. ## Custom MCP servers When a tool has no listing in Integrations, register its MCP server and Indent uses it like any other, including internal APIs and documentation systems. In [**Integrations**](https://app.indent.com/integrations), select **Create custom integration**. The form asks for: - **Endpoint URL** — the server's address. - **Display name** — how the integration appears in Indent. - **Connect for** — whether the connection is for your organization or your personal account. - **Transport** — Streamable HTTP or SSE, under **Advanced**. - **Authentication** — OAuth, API token, Basic auth, custom headers, or none, under **Advanced**. - **Description** — an optional explanation of what the server provides, under **Advanced**. ## Change or remove a connection For an organization connection, open the connected server from [**Integrations**](https://app.indent.com/integrations) and select **Edit connection**. For a personal connection, select **View details**. On the connection page, select **Edit config** to replace static credentials or change other editable settings. Saved tokens and headers are hidden, so re-enter them to save any change. **Test connection** checks the settings before you select **Save changes**. OAuth connections also use **Reconnect** to renew authorization. If an OAuth connection exposes editable configuration, **Edit config** remains available and reconnects when you save. For a custom MCP server, an admin can select **Rename** to change its display name. Its endpoint, transport, authentication method, and description cannot be changed after registration. Delete and register the custom integration again to change those fields. **Disconnect** removes the selected organization or personal connection. Where the server supports revocation, Indent also revokes its access. Admins can choose **Delete integration** on a custom server, which disconnects everyone using it. Indent keeps its own copy of each server's tool list, refreshed every few minutes. A server that's slow or briefly unreachable doesn't stall a session; when a call does fail, Indent reports what the server returned and decides whether to retry. ## Reconnect a connection that needs attention A connection marked **Needs attention** means one of two things: its sign-in has expired, or Indent has started asking for a permission that connection was never granted. In the second case the connection keeps working for everything it could already do, and only the new capability fails. Open the connection and select **Reconnect** to authorize the permissions Indent asks for today. Reconnecting updates the connection you already have, at the same scope, rather than adding a second one. ## Scopes Every integration connects at one of two scopes: - **Organization** — the connection is shared with your team, and anyone in the organization can use it. - **Personal** — the connection is owned by you, and only you can use it. Open [**Integrations**](https://app.indent.com/integrations), select the server, and select **Connect personal account**. Personal integration tools work only in a [private session](/collaborating/personal-and-private). Teammates can see whether you have connected a personal account, but they cannot use it. When a server authorizes a person rather than an application — as Notion's hosted MCP server does — an organization-scoped connection inherits the permissions of whoever completed the flow. Authorize those as a service account your team owns, not from a personal account; see [Connecting Notion](/connecting/notion#use-a-service-account-for-organization-scope) for the pattern. Listed and custom MCP servers can support personal connections. Database connections, GitHub App installations, and the Slack workspace app are organization-scoped. GitHub and Slack also offer personal account connections. # Connecting Notion > Connect the Notion MCP integration through a personal or organization-scoped account so Indent can search and edit your docs. Source: https://docs.indent.com/connecting/notion/ · Markdown: https://docs.indent.com/connecting/notion/index.md Connecting Notion gives Indent your docs and wikis as a tool. Ask it to find a spec, summarize a meeting note, pull the runbook for an alert, or write results back to a page, and it works with Notion directly. ## Connect Notion 1. **Open the integrations page** Open [**Notion in Integrations**](https://app.indent.com/integrations/mcp%3Anotion). 2. **Choose a scope** Select **Connect service account** to share the connection with your organization, or **Connect personal account** to connect as yourself. A personal integration works only in a [private session](/collaborating/personal-and-private). 3. **Authorize with Notion** Notion connects through its hosted MCP server. Sign in, choose the workspace, and select the pages and teamspaces to share. Indent can then use Notion in your sessions. > **Caution** > > Notion's hosted MCP server authorizes a **person**, not an application. Whoever completes the flow > lends the integration their own Notion permissions, so an organization-scoped connection made from > a personal account gives the whole team that person's access — and breaks when they leave or lose > a permission. Authorize it as a service account instead. ## Use a service account for organization scope A Notion service account is an ordinary workspace member that belongs to the team rather than to a person. Create one before you connect at organization scope. 1. **Create an account on a shared address** Sign up for Notion with an address your team controls, such as a group alias like `indent@yourcompany.com`. Keep the credentials in your password manager, not in one person's inbox. 2. **Invite it to the workspace** From **Settings → People** in Notion, invite the address as a member. Give it the lowest role that still does the job — **Member**, not **Workspace owner** — so the integration can't change workspace settings. 3. **Grant only the content Indent should see** Add the service account to the teamspaces and share the pages you want Indent to work with. The integration can reach exactly what this account can reach, so this list is your access boundary. 4. **Authorize Indent as that account** Sign in to Notion as the service account (a separate browser profile or incognito window avoids signing out of your own), then open [**Notion in Integrations**](https://app.indent.com/integrations/mcp%3Anotion), select **Connect service account**, and complete the OAuth flow. Auditing and offboarding then work the way you'd expect: Notion attributes Indent's edits to the service account, you widen or narrow the integration's reach by changing that account's page access, and revoking the connection is a single member to disable. > **Note** > > Notion bills service accounts as members on paid plans, and some workspaces restrict who may > install connections. Check with a workspace owner before creating one. ## If you need a workspace-owned bot Notion's hosted MCP server accepts OAuth only — it won't take an internal integration token — so a service account is as close to an application identity as the hosted server gets. When your policy requires a workspace-owned bot with no user session behind it, you can run Notion's open-source MCP server yourself with an internal connection token and register it in Indent as a [custom MCP server](/connecting/mcp-servers#custom-mcp-servers) with **API token** authentication. Notion no longer actively maintains that open-source server, so review and operate it as your own infrastructure. ## What Indent does with Notion - Searches your workspace and reads pages and databases. - Creates pages and writes results back into existing ones. - Comments on pages. - Queries databases and updates their entries. ## Next steps - [Connecting MCP servers](/connecting/mcp-servers) — the built-in MCP catalog and how scopes work. - [Permissions and data](/administration/permissions-and-data) — what Indent can reach and how access is scoped. # Connecting Sentry > Connect Sentry so Indent can pull in error reports and stack traces. Source: https://docs.indent.com/connecting/sentry/ · Markdown: https://docs.indent.com/connecting/sentry/index.md With Sentry connected, Indent can trace a production error back to the code that caused it during an [incident investigation](/working-with-indent/investigating-incidents). ## Connect Sentry 1. **Find Sentry** Open [**Sentry in Integrations**](https://app.indent.com/integrations/mcp%3Asentry). 2. **Choose a scope** Select **Connect service account** to share the connection with your organization, or **Connect personal account** to use your own Sentry access in private sessions. 3. **Authorize with Sentry** You're redirected to Sentry's hosted MCP server at [mcp.sentry.dev](https://mcp.sentry.dev) to approve access through OAuth. Sentry connects at organization or personal scope. See [Connecting MCP servers](/connecting/mcp-servers) for how scopes work. # Connecting Slack > Connect your Slack workspace so Indent can work with you in channels, threads, and direct messages. Source: https://docs.indent.com/connecting/slack/ · Markdown: https://docs.indent.com/connecting/slack/index.md Connecting Slack lets Indent work alongside your team in the tool you already talk in, and link long-running work back to a session in the web app. ## Connect Slack 1. **Connect your workspace** Open [**Slack in Integrations**](https://app.indent.com/integrations/slack) and select **Install Slack app**. This is an organization install and may need an administrator's approval. You can select **Connect personal account** on the same page to link your Slack identity. 2. **Invite Indent to a channel** In the channel you want to use, run `/invite @indent`. 3. **Start working** Mention `@indent` with a request. Indent replies in a thread and links long-running work as a session. The Slack workspace app connects at organization scope, so your whole team shares one workspace connection. The personal account connection is separate and owned by you. ## What Indent does in Slack - Answers questions and takes on tasks when you mention `@indent` in a channel. - Replies in a thread and links a session for long-running work. - Runs as a private session in a direct message, visible only to you. - Follows [automations](/automating/automations) — standing instructions attached to a channel with `@indent /automate `. Channel threads stay visible to your organization. ## Next steps - [Working with Indent in Slack](/collaborating/working-in-slack) — the full set of ways to work from channels, threads, and direct messages. - [Creating automations in Slack](/automating/automations) — give Indent standing instructions for a channel. # Connecting Tailscale > Put Indent's computers on your tailnet so sessions can reach services that aren't on the public internet. Source: https://docs.indent.com/connecting/tailscale/ · Markdown: https://docs.indent.com/connecting/tailscale/index.md A session running in an environment with Tailscale reaches the same private services your team reaches: an internal API, a staging database, anything behind a subnet router. Each computer joins your tailnet as a tag-owned, ephemeral node. Your access control policy decides what it reaches. Tailscale removes the node about an hour after it goes offline. A session suspends when it's been idle, which takes its computer offline. A session suspended for long enough loses its node and rejoins your tailnet with a new address when it resumes. > **Note** > > Connected database queries run from Indent's infrastructure and do not use the computer's tailnet. > To query a tailnet-only database, run a database client directly on the computer instead. See > [Connecting your database](/connecting/databases). ## Requirements - Owner, Admin, IT admin, or Network admin access to your tailnet. - An [environment](/getting-started/environments) for the repository your sessions run in. ## Prepare your tailnet 1. **Create a tag** Add `tag:indent` to `tagOwners` in your [access control policy](https://login.tailscale.com/admin/acls). ```json "tagOwners": { "tag:indent": ["autogroup:admin"], }, ``` 2. **Grant the tag access** A computer reaches nothing until a grant names its tag. ```json "grants": [ { "src": ["tag:indent"], "dst": ["tag:staging"], "ip": ["tcp:443", "tcp:5432"], }, ], ``` 3. **Create an OAuth credential** On the [Trust credentials](https://login.tailscale.com/admin/settings/trust-credentials) page, generate an OAuth credential with **Keys → Auth Keys → Write** and the tag `tag:indent`. Copy the client secret. Tailscale shows it once. An OAuth client secret doesn't expire. An auth key expires after at most 90 days. ## Configure the environment Open the environment from [**Settings → Environments**](https://app.indent.com/settings/environments) and select the **Configure** step. 1. **Ask Indent to install Tailscale** Indent writes the Dockerfile, so ask it to install Tailscale from `tailscale.com/install.sh`. The Dockerfile gains a line like this one: ```dockerfile RUN curl -fsSL https://tailscale.com/install.sh | sh ``` The Tailscale daemon starts when the computer boots. 2. **Add the client secret to Runtime variables** Select **Add variable**, enter `TS_AUTHKEY` as the key, and paste the client secret as the value. The saved value is masked in the app and injected into the computer's shell and background processes as `TS_AUTHKEY`. Use **Runtime variables** rather than **Build variables**. The latter applies to the build, and the secret is needed while the computer is running. 3. **Add a process that joins the tailnet** Under **Processes**, select **Add process**, name it `tailscale`, and set its **Command** to: ```bash while true; do sudo tailscale status >/dev/null 2>&1 || sudo tailscale up --auth-key="${TS_AUTHKEY}?ephemeral=true&preauthorized=true" --advertise-tags=tag:indent --hostname="indent-${COMPUTER_ID}" --accept-routes --shields-up; sleep 30; done ``` `ephemeral=true` registers a node that Tailscale removes on its own. `preauthorized=true` skips device approval. `--shields-up` blocks inbound connections, so the computer reaches your tailnet and your tailnet does not reach the computer. `--accept-routes` picks up the routes your subnet routers advertise. Names resolve through MagicDNS when your tailnet has it enabled. `COMPUTER_ID` is set on every computer, so each node gets its own name. The loop rejoins the tailnet after a suspension long enough to have removed the node. ## Confirm it works Select **Build + Verify**, then **Publish**. Start a session in the environment and ask Indent to run `tailscale status`, or to reach one of the services you granted. The node appears on your [Machines](https://login.tailscale.com/admin/machines) page as `indent-`. > **Caution** > > Anyone who can start a session in the environment reaches every service the grant allows, and so > does the code Indent runs there. Grant the narrowest set of destinations and ports the work needs. ## Revoke access Revoke the credential on the [Trust credentials](https://login.tailscale.com/admin/settings/trust-credentials) page to stop new computers from joining. Computers already on your tailnet keep their access. Delete their nodes on the [Machines](https://login.tailscale.com/admin/machines) page, or ask Indent to run `tailscale logout`, which removes a node immediately. ## Troubleshooting Ask Indent to read `~/.indent/background-processes/tailscale.log`. - `API token invalid` — the secret in `TS_AUTHKEY` is wrong or revoked. - `requested tags are invalid or not permitted` — the credential doesn't own `tag:indent`. - The node joins and reaches nothing — no grant names `tag:indent`. - A tailnet with Tailnet Lock enabled rejects node keys that a signing node hasn't signed. This setup doesn't sign them. ## Next steps - [Setting up environments](/getting-started/environments) — build the environment this configuration goes in. # Getting started > New to Indent? Start here: what it is, who it's for, and how to run your first task. Source: https://docs.indent.com/getting-started/ · Markdown: https://docs.indent.com/getting-started/index.md New to Indent? The [overview](/) walks through what Indent does for engineering and for knowledge work, and how to run your first task. This section goes deeper on the mental model and on setting Indent up to run your stack. - **What Indent can do** — Indent for engineering and for knowledge work: what it connects to, the tasks it runs, and where you work with it. - **How Indent works** — The mental model behind Indent: a session, the computer it runs on, how it verifies its work, and what it can access. - **Setting up environments** — Build a reusable computer setup so a session can start with your application built, its services running, and its tests ready. # Setting up environments > Build a reusable computer setup so a session can start with your application built, its services running, and its tests ready. Source: https://docs.indent.com/getting-started/environments/ · Markdown: https://docs.indent.com/getting-started/environments/index.md An environment defines the dependencies to install, the services to run, and a check that confirms the setup works. You build and publish it once, then reuse it for any session. A repository can belong to several environments. An environment can hold several repositories. ## What an environment contains - **Dockerfile** — starts from `indent/base` and installs your toolchain and dependencies. Indent writes it for you. - **Repositories**: the repositories Indent clones during the build. New environments track each repository's default branch. - **Build variables** — values available to the build. - **Runtime variables** — values available on a running computer. Their names appear in the session context, and commands and background processes can read their values. - **[Processes](/cloud-sessions/processes)** — the long-running services that make up your stack, such as a web server, a database, and a cache. Indent starts each one when the computer boots and restarts it if it exits. - **Verification goals** — what the environment should be able to do, in plain language, such as "the app builds" and "the UI loads." Indent turns them into one script that checks them. ## Create an environment Open the environment wizard from [**Settings → Environments**](https://app.indent.com/settings/environments), or from [**Settings → Repositories**](https://app.indent.com/settings/github-repositories) by selecting **Setup Environment** on a repository. 1. **Setup** Name the environment, choose the repositories, and write the verification goals in plain language. 2. **Configure** Tell Indent what the application needs, and it writes the Dockerfile and the verification script. Edit the variables and processes yourself in the same step. 3. **Build** Indent builds the image and boots a computer. A first build can take several minutes. 4. **Verify** Indent runs the verification script and, for anything with a UI, opens it in the browser to confirm. When everything passes, select **Publish**. New sessions can now start in the environment. Pushes to a tracked branch are combined into one rebuild after a 30-minute debounce window. A push received while a build is running does not schedule another build. ## Run verification yourself Select **Run verification** at any point after a successful build to re-run the checks — while you're getting the setup right, or later when you want to confirm the environment still works. If no computer is running, Indent boots one for the run. The **Verify** step appears once there's something to verify, and stays inactive until a build has succeeded. ## Work in an environment Select an environment from the dropdown when you start a new session. The session starts in that environment with your services already running. Without an environment, a session runs in a plain sandbox. ## Test through the browser Indent has a real web browser on its computer. Ask Indent to open your running application and click through a flow. Indent navigates your pages, fills in forms, and captures screenshots. You can watch or take control from the cloud session's [Browser tab](/cloud-sessions/browser). ## Secrets When an environment needs a secret, such as an API key or database password, provide it through the app. Saved values are masked after you enter them. Runtime variables are available to commands and background processes on the session's computer. See [Permissions and data](/administration/permissions-and-data). Connect the code Indent works in before you build an environment: [Connecting GitHub](/connecting/github). # How Indent works > The mental model behind Indent: a session, the computer it runs on, how it verifies its work, and what it can access. Source: https://docs.indent.com/getting-started/how-indent-works/ · Markdown: https://docs.indent.com/getting-started/how-indent-works/index.md Indent completes tasks by executing real tool calls — shell commands, file edits, database queries, browser actions — on a real computer, then reports what it did and how it verified the result. ## A session You work with Indent in a session. You give it a task, it does the work and reports back, and you keep going from there. A session retains its full context, so you and your teammates can pick up where the last message left off. Organization-visible sessions are multiplayer. Teammates join with full context, and Indent knows who's on the team. Sessions are visible to your organization by default. If you created a session, you can make it private from the share control in the session header. Making a session private is permanent. See [Multiplayer sessions](/collaborating/multiplayer) and [Private sessions](/collaborating/personal-and-private). ## The computer a session runs on Every session runs on a real computer, where Indent runs commands and edits files the way you would at a terminal. - **Cloud sandbox** — by default a session runs in a clean cloud sandbox. Point it at a [development environment](/getting-started/environments) to start with your app built, its services running, and its tests ready. - **Local computer** — the [desktop app](/working-locally/desktop) runs a session on your own computer, in a folder you choose, for work with local files and tools. A desktop local session is always private. ## How Indent verifies its work Indent doesn't assume a change worked — it checks. It runs the tests, reruns the query, reads the logs, or opens the running app in a real browser and clicks through the flow. When it reports back, it tells you what it verified and how, so you can trust the result or see exactly where it stopped short. ## What Indent can access Indent acts only through the tools you connect and within the access you grant. - **Connected integrations only** — Indent works with the integrations you've connected and the ones you select for a session, nothing else. - **Database permissions** — PostgreSQL and ClickHouse enforce read-only queries. BigQuery uses the connected service account's IAM permissions, so connect a read-only account to prevent writes. - **Secrets provided through the app** — saved values are masked after entry. Runtime variables are available to commands and background processes on the session's computer. - **Organization or personal scope** — organization connections are shared with the team; personal connections are owned by one person. Personal integration tools run only in private sessions. A connected personal GitHub account can also author pull requests requested by its owner in any session where they participate. For the full picture, see [Permissions and data](/administration/permissions-and-data). # Learning over time > How Indent retains context through memory it builds and instructions you commit. Source: https://docs.indent.com/learning/ · Markdown: https://docs.indent.com/learning/index.md How Indent retains context through memory it builds and instructions you commit. - **Memories** — Indent keeps a memory across sessions, recording durable facts and applying them in later work. - **AGENTS.md** — Put repository-level instructions at the root of the repo so Indent knows how your codebase works. - **Adding skills** — Package a reusable workflow as a committed SKILL.md in a repository connected through the GitHub App, so Indent pulls it in when a task matches. # AGENTS.md > Put repository-level instructions at the root of the repo so Indent knows how your codebase works. Source: https://docs.indent.com/learning/agents-md/ · Markdown: https://docs.indent.com/learning/agents-md/index.md Put `AGENTS.md` at the root of a repository to keep setup, architecture, and conventions with the code. In a local desktop session started from that folder, Indent loads the first 16 KiB at session start. In a cloud session, the file is available in the cloned repository but is not loaded automatically, so ask Indent to read it before starting work. ## What belongs here Use `AGENTS.md` for guidance that applies across most tasks in the repository — the kind of thing you'd tell a new teammate on their first day: - **Setup and key commands** — how to install dependencies, run the development server, run tests. - **Architecture** — how the codebase is organized, what the major modules are, where to find things. - **Conventions** — naming patterns, file structure rules, import ordering, error handling style. - **Testing expectations** — what kinds of tests are expected for different types of changes. - **Deployment and rollout** — how releases work, what environments exist, any gates or constraints. ## Example ```md # AGENTS.md ## Setup - `pnpm install` to install dependencies - `pnpm dev` to start the development server on port 3000 - `pnpm test` to run the test suite (Jest) ## Architecture - `src/api/` — Express route handlers, one file per resource - `src/services/` — business logic, no direct database access - `src/db/` — Prisma schema and migrations - `src/workers/` — background job processors (BullMQ) ## Conventions - Use named exports, not default exports - Error responses use `src/lib/errors.ts` helpers, never raw status codes - All new API endpoints need an integration test in `tests/api/` ## Testing - Unit tests live next to the file they test (`foo.test.ts`) - Integration tests go in `tests/api/` and run against a real Postgres instance - Run `pnpm test:integration` separately — these require Docker ## Deployment - Main branch auto-deploys to staging - Production deploys go through the `release` branch and require a passing CI check - Database migrations run automatically on deploy — never run them manually ``` ## AGENTS.md, memory, and skills `AGENTS.md`, memory, and skills all give Indent context that persists, but each fits a different kind of guidance. - **`AGENTS.md`** holds repository facts that stay true across most tasks. You write it and commit it to the repository, so it is versioned and reviewed in pull requests. Local desktop sessions load the first 16 KiB from the selected folder automatically; in cloud sessions, ask Indent to read the file. Use it for setup, architecture, conventions, testing, and deployment. - **[Memory](/learning/memory)** holds durable context Indent learns as it works. Memories can apply to a person, organization, repository or integration, or automation. Use them for preferences, cross-repository conventions, resource-specific facts, and details you teach Indent in passing. - **[Skills](/learning/skills)** hold a specific, repeatable procedure that's too narrow for `AGENTS.md`. You commit a skill to the repository, and Indent pulls it in only when a task matches. Use it for a workflow like deploying one service or triaging a class of incident. # Memories > Indent keeps a memory across sessions, recording durable facts and applying them in later work. Source: https://docs.indent.com/learning/memory/ · Markdown: https://docs.indent.com/learning/memory/index.md Indent learns as you work, without being asked, and you can also tell it something to remember directly. It applies what it knows in later sessions where that memory's scope is relevant. ## What Indent remembers Indent remembers durable facts worth applying next time: - Your preferences for how work is done and how results are reported. - Your team's conventions and definitions. - Facts about your systems, such as a table's quirks or a service's setup. - Steps for a task you walked it through. It doesn't keep passing details, such as the state of a single task. ## How you teach it Indent learns as you work, without being asked, and it captures your corrections. Tell it to do something a certain way, and it applies that in later sessions. You can also ask it directly to remember something. ## What's personal and what's shared Indent files each memory by what it concerns. What Indent learns about you stays personal to you. What Indent learns about your organization is shared with your team, so a new convention applies for everyone. Integrations and automations also form their own memories over time. ## See what Indent knows Open the [**Memory**](https://app.indent.com/memory) page in the web app to browse and search what Indent has learned. You can also ask Indent to add, change, or remove a memory directly in a session. ## AGENTS.md, memory, and skills `AGENTS.md`, memory, and skills all give Indent context that persists, but each fits a different kind of guidance. - **[`AGENTS.md`](/learning/agents-md)** holds repository facts that stay true across most tasks. You write it and commit it to the repository, so it is versioned and reviewed in pull requests. Local desktop sessions load the first 16 KiB from the selected folder automatically; in cloud sessions, ask Indent to read the file. - **Memory** holds durable context Indent learns as it works. Memories can apply to a person, organization, repository or integration, or automation. Use them for preferences, cross-repository conventions, resource-specific facts, and details you teach Indent in passing. - **[Skills](/learning/skills)** hold a specific, repeatable procedure that's too narrow for `AGENTS.md`. You commit a skill to the repository, and Indent pulls it in only when a task matches. Use it for a workflow like deploying one service or triaging a class of incident. # Adding skills > Package a reusable workflow as a committed SKILL.md so Indent pulls it in when a task matches. Source: https://docs.indent.com/learning/skills/ · Markdown: https://docs.indent.com/learning/skills/index.md A skill is a reusable workflow — a repeatable procedure too narrow for [AGENTS.md](/learning/agents-md) but too important to explain every time. ## Where they live Commit skills under `.agents/skills/` in a repository available through your organization's GitHub App connection. Each skill gets its own directory, one level deep, containing a `SKILL.md` and any supporting files it needs. ```text .agents/ skills/ deploy/ SKILL.md scripts/ deploy.sh db-migration/ SKILL.md incident-triage/ SKILL.md references/ runbook.md ``` Because skills are committed to the repository, they are versioned and reviewed in pull requests alongside your code. ## What goes in SKILL.md Every `SKILL.md` must start with YAML frontmatter, or Indent skips the skill. The frontmatter needs: - `name` — a path-safe identifier matching `^[a-z0-9_-]+$`. - `description` — a non-empty line describing when the skill applies. After the frontmatter, write when to use the skill and the steps to follow. The more concrete the instructions, the more reliably Indent executes the workflow. ### Example: deploy ```md --- name: deploy description: Deploy a service to staging or production. --- # Deploy ## When to use When deploying a service to staging or production. ## Steps 1. Run `pnpm build` and confirm it succeeds 2. Run `pnpm test` — do not deploy if tests fail 3. For staging: push to the `staging` branch 4. For production: create a pull request to the `release` branch - Title format: `release: ` - Wait for CI to pass before merging 5. After merge, monitor the Datadog dashboard "Service Health" for 10 minutes before confirming the deploy is stable ## Notes - Never force-push to `release` - If a deploy needs to be rolled back, revert the merge commit and push to `release` again ``` ### Example: db-migration ```md --- name: db-migration description: Add or change the database schema safely. --- # Database migration ## When to use When a task requires changes to the database schema. ## Steps 1. Create the migration with `pnpm prisma migrate dev --name ` 2. Check that the generated SQL in `prisma/migrations/` looks correct 3. If the migration is destructive (dropping columns, changing types), add a two-phase approach: - First pull request: make the column nullable or add the new column - Second pull request: backfill data and remove the old column 4. Run `pnpm test:integration` to verify against a real database 5. Note in the pull request description that this includes a migration ## Notes - Migrations run automatically on deploy — they must be backward-compatible with the currently running code - Never edit a migration that has already been applied to staging or production ``` ### Example: incident-triage ```md --- name: incident-triage description: Investigate a production incident or alert. --- # Incident triage ## When to use When investigating a production incident or alert. ## Steps 1. Check the Datadog dashboard for the affected service 2. Pull recent error logs from Sentry for the relevant time window 3. Identify whether the issue correlates with a recent deploy — check the last 3 merged pull requests on the `release` branch 4. If a deploy caused it, draft a revert pull request 5. If not deploy-related, investigate the error stack trace and check for recent changes to the affected code paths 6. Write up findings as a comment in the incident thread ## References - See `references/runbook.md` for service-specific escalation paths ``` ## When Indent picks up a change Indent reads skills from the default branch of repositories available through your organization's GitHub App connection and refreshes them within a few minutes of a push. A skill on another branch isn't picked up until it merges. A `SKILL.md` whose frontmatter is missing or invalid is skipped without an error, so if a new skill never gets used, check `name` and `description` first. A repository can hold up to 256 skills. ## AGENTS.md, memory, and skills `AGENTS.md`, memory, and skills all give Indent context that persists, but each fits a different kind of guidance. - **[`AGENTS.md`](/learning/agents-md)** holds repository facts that stay true across most tasks. You write it and commit it to the repository, so it is versioned and reviewed in pull requests. Local desktop sessions load the first 16 KiB from the selected folder automatically; in cloud sessions, ask Indent to read the file. - **[Memory](/learning/memory)** holds durable context Indent learns as it works. Memories can apply to a person, organization, repository or integration, or automation. Use them for preferences, cross-repository conventions, resource-specific facts, and details you teach Indent in passing. - **Skills** hold a specific, repeatable procedure that's too narrow for `AGENTS.md`. You commit a skill to the repository, and Indent pulls it in only when a task matches. Use it for a workflow like deploying one service or triaging a class of incident. # Working locally with Indent > Run Indent on your own machine to work with local files and tools. Source: https://docs.indent.com/working-locally/ · Markdown: https://docs.indent.com/working-locally/index.md Run Indent on your own machine to work with local files and tools. - **Indent Desktop** — Run Indent on your own computer, in a folder you choose, to work with local files and tools. - **Terminal** — Open a shell on the computer a session runs on and work alongside Indent. # Indent Desktop > Run Indent on your own computer, in a folder you choose, to work with local files and tools. Source: https://docs.indent.com/working-locally/desktop/ · Markdown: https://docs.indent.com/working-locally/desktop/index.md The desktop app runs Indent on your own computer instead of in a cloud sandbox — so it can work with local files and tools such as spreadsheets, PDFs, and images. ## Install the app The desktop app requires macOS with Apple Silicon. From the web app menu, choose **Download desktop app**, or download it directly from [app.indent.com/download/mac](https://app.indent.com/download/mac). Open the disk image, drag Indent to Applications, eject the disk image, and launch Indent from Applications. ## Sign in Open the app and select **Sign in**. Indent opens your browser to complete sign-in. ## Keep the app up to date **Settings → Desktop** shows the **Version** running on this device. Select **Check for updates** to look for a newer one; when an update has downloaded, **Restart to update** installs it. Leave **Automatic updates** on to download new versions in the background. A downloaded update installs when you quit the app or select **Restart to update**. ## Open a session in the app In the web app, any session's menu in the sidebar has **Open in desktop app**. An `indent://` link opens and focuses the app the same way. Inside the app, **Cmd+N** starts a new session. ## Choose local or cloud The desktop app adds a **Local / Cloud** switch next to the message box: - **Cloud** — Indent works in a cloud sandbox within a given [environment](/getting-started/environments), like in the web app. - **Local** — Indent works on your computer, within a folder you choose. Set this before you start a session. A session's compute is fixed once it starts. ## Work on your computer In Local mode, ask Indent to do anything you'd do at a terminal in that folder: run the application, run tests, edit files, use git. Indent acts on your real computer, so treat a local session the way you'd treat running those commands yourself. To run commands yourself alongside it, open the [Terminal](/working-locally/terminal). A session that runs on your computer in the desktop app is always a [private session](/collaborating/personal-and-private). # Terminal > Open a real shell on the computer a session runs on, next to the chat, and work alongside Indent. Source: https://docs.indent.com/working-locally/terminal/ · Markdown: https://docs.indent.com/working-locally/terminal/index.md Every session has a **Terminal** tab in the tool panel: an interactive shell on the same computer the session runs on. In the desktop app in Local mode that's your own machine. In a cloud session it's the sandbox. The tab is in the web app too, so a terminal is one click away wherever the session is open. ## Open a terminal Select **Terminal** in the tool panel toolbar at the top of the session. Opening the tab starts a shell if none is running, and the **Shell** chip in the transcript opens the same panel. ![The Terminal tab in the session tool panel, running git log in the session's working directory](/images/terminal-panel.png) - **New terminal** adds another shell. Tabs reorder by dragging, and each tab shows its exit status once its shell ends. - Closing the last tab closes the panel. - The shell runs on the computer, not in the window. Reload the app or lose the connection and the terminal reattaches with its scrollback intact. ## What you're connected to The terminal and Indent share the computer, not the shell. You see the same files, services, and ports, but each has its own shell process, so history, shell variables, and the current directory are separate. - **Local session** — your own machine, running your login shell with your environment. Commands run with your account's access, so treat the terminal the way you'd treat any shell on your machine. It opens in the app's working directory rather than the folder the session uses, so `cd` there first. - **Cloud session** — the sandbox, starting in `/workspace`, with the [environment](/getting-started/environments) variables the session was configured with already set. Opening the tab wakes a sandbox that has gone to sleep. ## It's a real terminal The panel is a full terminal emulator, not a command box: colors, mouse reporting, and full-screen programs such as `vim` and `htop` all work. It resizes with the panel, and scrollback is there through the scrollbar or Shift+Page Up and Shift+Page Down. Selecting text copies it. Paste with Cmd+V on macOS, or Ctrl+Shift+V elsewhere; plain Ctrl+V passes through to the program you're running. > **Note** > > Two neighboring tabs show shells you don't type into: **Bash** is a read-only view of the commands > Indent runs, and [**Processes**](/cloud-sessions/processes) shows the services an environment > starts in a cloud session. # Working with Indent > The everyday tasks you hand Indent: writing code, querying data, investigating incidents, and getting good results. Source: https://docs.indent.com/working-with-indent/ · Markdown: https://docs.indent.com/working-with-indent/index.md The everyday tasks you hand Indent: writing code, querying data, investigating incidents, and getting good results. - **Writing code** — Hand Indent a coding task and it goes from prompt to pull request, then keeps working through review and CI. - **Reviewing pull requests** — Indent reviews pull requests, posts findings on GitHub, and works with you in the comments to get them ready to merge. - **Querying and analyzing data** — Ask questions in plain language and Indent writes SQL, returns downloadable results and charts, and writes up findings. - **Reports** — Publish durable work, browse and revise reports, leave feedback, and export or share the result. - **Investigating incidents** — Indent pulls context across logs, traces, errors, and data to root-cause a production issue and carry it to a fix. - **Getting good results from Indent** — Frame tasks well, give the right context, and set Indent up to get better at your work over time. - **Troubleshooting** — What to do when Indent is stuck, takes a wrong approach, hits failing checks, suspends a session, or lacks access. - **Archiving sessions** — Take a session out of your list without deleting it, find it again on the Archive tab, and bring it back. # Archiving sessions > Take a session out of your list without deleting it, find it again on the Archive tab, and bring it back. Source: https://docs.indent.com/working-with-indent/archiving-sessions/ · Markdown: https://docs.indent.com/working-with-indent/archiving-sessions/index.md Archiving takes a session out of your session list. The history stays, and you can bring the session back at any time. ## Archive a session Every session list has an **Archive** action: - **Sidebar** — hover a session row and click the archive icon, or right-click the row and choose **Archive**. ![A hovered session row in the sidebar, with the archive icon at the end of the row](/images/archive-sidebar-row.png) - **Session header** — open the ⋯ menu in the header of an open session and choose **Archive**. ![The overflow menu in a session header, open on Archive](/images/archive-session-menu.png) - **Home page** — hover a row and click the archive icon, or right-click the row and choose **Archive**. ![A hovered row on the home page, with the archive icon beside the row's other actions](/images/archive-home-row.png) Archiving takes effect immediately. **Delete**, in the same menus, is irreversible. Archiving a session that Indent is still working on stops the work, the same way interrupting it does: tool calls in flight are cancelled, the partial reply stays in the history, and the session ends up halted. Anything that arrives afterward is queued, so activity on a [pull request the session is subscribed to](/working-with-indent/reviewing-pull-requests) is processed once the session comes back. Archiving applies to the session, so it also leaves your teammates' lists, and anyone who can see a session can archive or unarchive it. ## Find an archived session Go to the home page and open the **Archive** tab, next to **Sessions**. It lists the archived sessions you started or took part in. The tab is part of the URL, so the view is shareable. That tab is the only list an archived session appears in. A teammate who never took part in one can't find it once it's archived, though a direct link to a session keeps working. ## Bring a session back Two ways: - **Unarchive it.** On the home page's **Archive** tab, right-click a row and choose **Unarchive**. The session returns to your sidebar and lists. - **Send it a message.** A new message from a person unarchives the session automatically, from any surface: the composer in the web app, a mention in the [Slack thread](/collaborating/working-in-slack) the session belongs to, or a comment on the [Linear issue](/connecting/linear) it was started from. Indent picks the work up with the full history. Opening an archived session leaves it archived. Only a new message brings it back. > **Note** > > Nothing is archived automatically. There's no inactivity timer, and an archived session is kept > for as long as any other. # Getting good results from Indent > Frame tasks well, give the right context, and set Indent up to get better at your work over time. Source: https://docs.indent.com/working-with-indent/getting-good-results/ · Markdown: https://docs.indent.com/working-with-indent/getting-good-results/index.md The best way to work with Indent is to treat it like a capable colleague. Say what you want, give it what it needs to get there, and check the result. ## Frame the task like a brief Hand Indent a task the way you'd hand one to a teammate. State the outcome you want, not the keystrokes to get there. - **Lead with the goal.** "Add rate limiting to the public API so a single client can't exceed 100 requests a minute" beats "edit the middleware file." - **Name the constraints and edge cases that matter.** The config that can't change, the endpoint that must stay backward-compatible, the deadline behavior. - **Say what "done" looks like.** Tests passing, a specific bug no longer reproducing, a number matching a known value. - **Don't over-specify the approach.** Give the destination and let Indent find the path; step in if it heads the wrong way. You don't have to get the framing perfect up front. Indent asks clarifying questions when something is ambiguous, and you can redirect it mid-session. ## Give it the right context Indent starts each session fresh. The context you provide, and the context you've set up in advance, decide how well it does. - **Attach what's relevant.** Paste a Sentry link, a stack trace, an error message, or a screenshot. You can attach up to 10 files or images to your prompts by drag-and-drop, paste, or the paperclip. ![The composer with an image and a file attached alongside a prompt](/images/composer-attachments.png) - **Point at a real environment when the task needs your build.** A bare sandbox has your code but not your running application. When a task needs the app built, services up, or the UI exercised in a browser, start the session in an [environment](/getting-started/environments) so everything is ready from the first message. For a quick code edit or a question, a sandbox is enough. - **Connect the systems the task touches** — [GitHub](/connecting/github), [databases](/connecting/databases), [Slack](/connecting/slack), [Datadog](/connecting/datadog), [Sentry](/connecting/sentry), and other [integrations](/connecting/mcp-servers) — so Indent can pull the evidence itself instead of asking you for it. ## Train Indent on your business, systems, and codebase - **[AGENTS.md](/learning/agents-md): standing repository instructions.** Commit an `AGENTS.md` at the repository root with setup, architecture, conventions, testing, and deployment guidance. A local desktop session started from that folder loads the first 16 KiB automatically. In a cloud session, ask Indent to read the file before starting work. - **[Skills](/learning/skills): named, reusable procedures.** Commit a `SKILL.md` for a workflow too narrow for AGENTS.md but too costly to re-explain, like a deploy, a migration, or a release runbook. Repositories available through the GitHub App publish matching skills to Indent. - **[Memories](/learning/memory): what Indent learns as it works.** Indent records durable facts on its own, and you can tell it to remember or drop something directly. Memories apply in later sessions where their personal, organization, repository, integration, or automation scope is relevant. Correct Indent once and it records the correction. The payoff: Indent can use the relevant context without another full explanation, so you spend less time repeating setup, procedures, and preferences. ## Review and verify the output Indent shows its work: the files it read, the commands it ran, and the queries it wrote. That lets you check its reasoning, not just its result. ![A run_query tool call showing the SQL Indent wrote and the rows it returned](/images/tool-query-panel.png) ![An inline diff of an edit Indent made to a file](/images/tool-diff-panel.png) - **Read the diff, not just the summary.** Open the pull request and review the change as you would a teammate's. - **Check the evidence behind a claim.** For an analysis, the SQL is inline with the results; for an incident, the logs and traces are in the transcript. - **Redirect in the session** when the approach is off. A follow-up message steers the work without starting over. See [Troubleshooting](/working-with-indent/troubleshooting) when Indent gets stuck or a check keeps failing. # Investigating incidents > Indent pulls context across logs, traces, errors, and data to root-cause a production issue and carry it to a fix. Source: https://docs.indent.com/working-with-indent/investigating-incidents/ · Markdown: https://docs.indent.com/working-with-indent/investigating-incidents/index.md Indent works an incident the way an on-call engineer would: gather evidence across your tools, find the root cause, then carry it straight into a fix — all in one session. ## Connect your tooling Connect the systems Indent should use during an investigation from [**Integrations**](https://app.indent.com/integrations): - **Slack** — Indent reads and posts in incident channels and direct messages. See [Connecting Slack](/connecting/slack). - **Datadog** — Indent pulls metrics, traces, and logs. See [Datadog](/connecting/datadog). - **Sentry** — Indent pulls error reports and stack traces. See [Sentry](/connecting/sentry). - **Databases** — Indent runs read-only queries against PostgreSQL and ClickHouse. BigQuery uses the connected service account's IAM permissions. See [Connecting your database](/connecting/databases). ## Start an investigation Start from a session or from Slack. Paste a Sentry link, describe what's happening, or mention `@indent` in an incident channel. For example: > @indent Checkout has been throwing 500s for a handful of orgs since the 2pm deploy. Sentry issue: > https://acme.sentry.io/issues/44182174/ Indent pulls context from your connected systems: querying Datadog for recent metrics, checking Sentry for related errors, and running database queries to trace the issue through your data. It asks clarifying questions when it needs to — what the user was doing, whether there was a recent deploy, what the expected behavior was — then works through the evidence to a root cause. ## From root cause to fix Once Indent has a root cause, the same session can continue into a code fix. Indent already has the full investigation context, so it opens a pull request with the fix without you re-explaining the problem. See [Writing code](/working-with-indent/writing-code). # Querying and analyzing data > Ask questions in plain language and Indent writes SQL, returns downloadable results and charts, and writes up findings. Source: https://docs.indent.com/working-with-indent/querying-data/ · Markdown: https://docs.indent.com/working-with-indent/querying-data/index.md Indent works as a data analyst for your team: it explores the schema, writes the query, runs it, and presents the results — no SQL from you. ## Query and explore Connect a database from [**Databases in Integrations**](https://app.indent.com/integrations?filter=databases). Indent supports PostgreSQL, BigQuery, and ClickHouse. Databases are always organization-scoped. See [Connecting your database](/connecting/databases). Once a database is connected, ask a question in plain language. Indent searches the schema, inspects tables, writes the query, and runs it. PostgreSQL transactions and ClickHouse connections enforce read-only access. BigQuery uses the connected service account's IAM permissions, so connect a read-only account to prevent writes. Results appear inline alongside the SQL that produced them, and you can download them as CSV. Ask follow-up questions against the same data, refine the query, or pivot to a different table in the same session. ## Charts and reports Indent generates charts inline when a result is clearer as a visualization — bar charts, line charts, and stacked bar charts. Indent also writes up a full analysis from the data it queried. Ask for a case study on a customer's product usage and Indent produces a written summary with key stats, quotes, and supporting charts, all from the same session. ## Start from Slack Mention `@indent` in a Slack channel and ask a data question directly: ``` @indent How many organizations signed up last week, broken down by day? ``` Indent runs the queries and replies in the thread. See [Working with Indent in Slack](/collaborating/working-in-slack). ## Move analysis into code When an investigation surfaces a bug, the same session can continue into a code fix. Indent already has the context — the queries, the data, the root cause — so it can move into the codebase and open a pull request. See [Writing code](/working-with-indent/writing-code). # Reports > Publish durable work, browse and revise reports, leave feedback, and export or share the result. Source: https://docs.indent.com/working-with-indent/reports/ · Markdown: https://docs.indent.com/working-with-indent/reports/index.md Reports are durable, versioned documents for investigations, audits, analyses, and other work people need to revisit. Ask Indent to **publish a report** when a result needs a home beyond the session. Indent returns a link when the report is published, and the report remains available after the session's computer is gone. ## Find and read reports Select **Reports** in the app sidebar to browse reports available to you. Search matches report titles. Use **Mine**, **Teammates**, **Bots**, and **All** to filter by creator. Private reports have a lock icon. Reports are ordered by their most recent publication. A report inherits the visibility of the session that first publishes it: - **Private** reports are visible only to the person who created the private session. - **Team** reports are visible to the organization. Each publication that changes the document or one of its assets creates a version. Open **Version history** to switch versions and see when and by whom each was published. Use the arrow beside a version to open its source session. From a report's full-page view, **Open chat** opens the source session for the selected version. ![A report with its version history open, showing two publications and their authors](/images/report-version-history.png) ## Ask for changes Open the report from its source session to leave feedback for Indent: 1. Select text in the report and choose **Comment**. 2. Write the change you want and choose **Comment** again. Repeat for any other passages. 3. Choose **Submit feedback to the agent** to send the comments without another message, or send your next chat message to include them with it. Comments remain drafts until they are submitted. They can be edited, deleted, or discarded first. Text comments are available in the report panel inside a session, not on the standalone Reports page. A revision stays on the same report as a new version, so existing report links continue to work. ## Download a report Open **Download** on the version you are viewing: - **Download as PDF** opens the browser's print flow for the rendered report. - **Download as ZIP** downloads the source Markdown and its report assets. Referenced files and images are stored with each report version. When a report uses an external image, Indent downloads it and publishes it as a report asset; a report cannot keep an external image URL embedded directly. ## Publishing limits - Publishing requires a cloud sandbox. A session attached only to a local computer cannot publish a report. - Subagents cannot publish reports themselves. The main session must publish the finished document. - External images must become report assets before publishing. Referenced files are copied into the report so they remain available with it. - `report.md` can be up to 2 MiB. Each referenced asset can be up to 25 MiB, with at most 100 assets and 100 MiB total per version. # Reviewing pull requests > Indent reviews pull requests, posts findings on GitHub, and works with you in the comments to get them ready to merge. Source: https://docs.indent.com/working-with-indent/reviewing-pull-requests/ · Markdown: https://docs.indent.com/working-with-indent/reviewing-pull-requests/index.md Indent reads the diff, runs and tests the code, works with you in the comments, and pushes commits to the branch — turning a raw pull request into one that's ready to merge. ## Start Indent's code review Start the review from the pull request on GitHub: - **Review one pull request** — add the **`indent`** label, or leave a top-level comment such as **`@indent review this pull request`**. Either trigger works when automatic reviews are off and overrides automatic author, branch, and draft filters. - **Review every new pull request** — open [**Settings → Code Review**](https://app.indent.com/settings/code-review), select the checkbox next to one or more repositories, and choose **Enable reviews**. You can also select a repository, turn **Enabled** on, and save the change. Both routes start the dedicated code review workflow. Indent posts one persistent review comment, adds inline findings where possible, and follows new commits and check results according to the repository's trigger mode. > **Code review starts on GitHub** > > Asking Indent to inspect a pull request in Slack or the web app starts a normal session. To get > the persistent review comment and follow-up behavior described on this page, trigger code review > from the pull request or ask the session to add the `indent` label for you. If the repository does not appear in Code Review settings, [connect it to GitHub](/connecting/github) first. Add the **`indent-ignore`** label to keep a pull request out of automatic review and block the **`indent`** label. A top-level **`@indent`** comment still starts a review. ## Configure reviews for a repository Open [**Settings → Code Review**](https://app.indent.com/settings/code-review), stay on the **Settings** tab, and select a repository to configure: - **Enabled** — review every eligible pull request when it opens. When this is off, Indent reviews only the pull requests you manually opt in to. - **Trigger mode**: how reviews continue after the first one. **Fully automatic** keeps reviewing as new commits and check results arrive. **Initial review only** runs one round, then waits for you to ask for another. - **Maximum review cost**: pause further reviews once a pull request reaches this amount. Leave it empty for no limit. - **Only review specific authors** / **Exclude authors** — limit automatic review to an allowlist of authors, or skip pull requests from specific authors. - **Default branch only** / **Source branch filters** — scope automatic reviews by target and source branch. - **Ignore draft PRs** — skip drafts and start when the pull request is marked ready. On by default. - **CI failure summary** — explain failed required checks. - **Wait for the review to finish before commenting** — hold the review comment until the review finishes, instead of posting incrementally. - **Environment** — run the review inside one of your [environments](/getting-started/environments) so Indent can build and test the code. When none is selected, the review uses the [organization default environment](/administration/organization-defaults#default-environment), if configured. ## Limit automatic reviews by branch Branch controls appear when **Enabled** is on: - **Default branch only** reviews only pull requests targeting the repository's default branch. - **Source branch filters** skip a pull request when its source branch matches any configured Unicode JavaScript regular expression. A match can occur anywhere in the branch name unless the pattern is anchored, as in `^dependabot/`. Invalid patterns cannot be saved. Existing repositories start unrestricted, with **Default branch only** off and no source branch filters. These controls apply only to automatic reviews; the manual triggers at the top of this page still start a review. ## Read the review Indent posts a single review comment and keeps it current as the pull request changes. It has these parts, in order: - **Issues**: each problem Indent found. An issue also appears as an inline comment when Indent can attach it to a relevant changed line. - **Review agents** — what each review agent found. Select an unchecked agent to run or rerun it. - **CI Checks** — the state of the required checks at the latest commit, and which ones failed. Each issue has a severity: - **Critical** — breaks functionality, security, or data. - **Bug** — incorrect behavior. - **Nit** — style or a minor point. For example, Indent raises an accessibility issue: > **Issues — 1 potential issue found** Locked-selector tooltips are hover-only: the tooltip trigger > is a non-focusable ``. Keyboard and screen-reader users focusing the actual control never > get the "can't be changed" explanation. ## Iterate in the comments Reply to keep working with Indent: - In an **inline thread**, reply directly. Indent responds without a mention. - In a **top-level comment**, mention `@indent`. Ask Indent to explain a finding or make a change. When you request a change, Indent edits the code, verifies it, and pushes a commit to the branch. For example, a reviewer rejects the proposed approach and Indent implements an alternative: > **jsegaran:** @indent I don't want to fail back compat. Lets have a default **indent:** Done — > switched `queryId` to `z.string().default("")` instead of required, so nothing breaks on back > compat. Added a decode test for a legacy call without `queryId`. Green locally: typecheck, lint, > fmt, and the events/agent/session-processor suites. A review is a [multiplayer session](/collaborating/multiplayer), so anyone on the team can join the comments and steer the work. You can also tell Indent to work directly with the pull request. `@indent rebase` rebases the branch onto its base, resolves conflicts, and force-pushes. ## Ask for another review In **Initial review only** mode, and on any pull request where Indent has stopped reviewing automatically, start a fresh round two ways: - Check **Select for re-review** in the review comment. - Mention `@indent` in a comment on the pull request. Either way Indent reviews the current head commit with the current check results, and reports which commit it reviewed. Adding the `indent` label doesn't start a round once Indent has stopped reviewing automatically. ## Cap what a review costs Set **Maximum review cost** on the repository to stop a single pull request from consuming an unbounded amount of credit. The amount is what the review is billed to your organization, at least $0.01, and an empty field means no limit. When a pull request reaches the limit, Indent stops reviewing new commits and says so in the review comment: > **Cost limit reached.** Indent will no longer automatically review PR updates. Request another > review below whenever needed. Each further round needs its own request — authorizing one round doesn't lift the cap for the rest of the pull request. ## When billing blocks a review If your organization is out of credits, its trial has ended, or it has reached its [spend limit](/administration/billing), Indent doesn't start the review and says which of those it was, with a **Manage billing** link. Raise the limit or add credits and ask for the review again. ## Autofix For an issue that Indent has a concrete fix for, you can apply the fix from the web app. Indent turns the fix into a commit made by the review session, then pushes it to the branch. ## Fix failing checks Indent watches the pull request as new commits and check results arrive. When a check fails, ask Indent in a comment to fix it, or tell it to get every check green. ## Review rules Encode your team's standards as review rules so Indent checks for them on every review. Rules are committed to the repository as `.mdc` files under `.indent/rules/`, versioned alongside your code. Each rule is a Markdown file with YAML frontmatter: - **`description`** — what the rule checks for. - **`globs`**: glob patterns that scope the rule to specific files. Omit this field to apply to all files. - **`when_to_use`** — additional context about when the rule applies. - **`alwaysApply`** — apply the rule to every review regardless of the globs. For example, `.indent/rules/security.mdc`: ```md --- description: Security review guidelines globs: "**/auth/**, **/tokens/**, **/secrets/**" when_to_use: When reviewing security-sensitive code alwaysApply: false --- # Security Guidelines - Never log secrets, tokens, or API keys - Validate all user input before processing - Use parameterized queries for database operations - Check authorization before performing sensitive operations ``` You can also give Indent repository guidance in [AGENTS.md](/learning/agents-md) and [Skills](/learning/skills). # Troubleshooting > What to do when Indent is stuck, takes a wrong approach, hits failing checks, suspends a session, or lacks access. Source: https://docs.indent.com/working-with-indent/troubleshooting/ · Markdown: https://docs.indent.com/working-with-indent/troubleshooting/index.md You fix most problems by telling Indent, in the session, what to do differently. Indent shows its work as it goes, so you can see where it went wrong and redirect it. ## Indent is stuck or took a wrong approach Send a message in the same session or Slack thread. You don't need to start over — Indent keeps the full context and adjusts. - **Point it at the problem.** "That's the wrong file — the handler lives in `src/api/`, not `src/routes/`." - **Correct the approach.** "Don't add a new dependency for this; use the existing helper in `lib/http.ts`." - **Reset the direction** when it has drifted. "Stop — let's step back. The goal is only to fix the timeout, not refactor the client." Indent records corrections as [memory](/learning/memory), so the same misstep is less likely next time. ## A review or CI check keeps failing When a check on the pull request fails, Indent reads the logs and pushes a fix on its own. If it doesn't catch one, or a fix doesn't clear the check: - Ask Indent to make all checks pass — comment on the pull request or message the session. - Tell Indent when a failure is unrelated to the change (a flaky test, a pre-existing break), and it won't chase it. - Comment `@indent rebase` on the pull request to rebase a stale branch. See [Writing code](/working-with-indent/writing-code) for how the session stays connected to the pull request. ## A session has suspended Sessions suspend when they've been idle. This is normal and nothing is lost. Send a new message and the session resumes with all its context intact — the same repository, findings, and connected integrations. ## Indent lacks access to something If Indent says it can't reach a repository, database, or tool, the integration isn't connected or isn't in scope for the session: - **Connect the integration** from [**Integrations**](https://app.indent.com/integrations). See [Connecting MCP servers](/connecting/mcp-servers) and the specific setup pages for [GitHub](/connecting/github), [Slack](/connecting/slack), and [databases](/connecting/databases). - **Personal integration tools require a private session.** Each integration's page shows whether a personal connection is available. Database connections, GitHub App installations, and the Slack workspace app are organization-scoped. GitHub and Slack also offer personal account connections. If the session is organization-visible, the picker asks you to make it private before selecting a personal integration. A personal GitHub account can also author pull requests you request in any session where you participate. See [Private sessions](/collaborating/personal-and-private). > **Note** > > If a task needs your application built and running and Indent only has a bare sandbox, set up an > [environment](/getting-started/environments) and start the session there. # Writing code > Hand Indent a coding task and it goes from prompt to pull request, then keeps working through review and CI. Source: https://docs.indent.com/working-with-indent/writing-code/ · Markdown: https://docs.indent.com/working-with-indent/writing-code/index.md Indent explores the codebase, plans the change, edits the code, runs linters and tests, and opens a pull request. You watch each step as it happens: which files it read, what it edited, and what commands it ran. Click an edit to open its diff beside the transcript. ![A session with the transcript on the left and an edit's diff open in the side panel](/images/session-diff-panel.png) ## From prompt to pull request Describe a bug, feature, or task in a session. Indent reads files, searches for references, and runs commands to understand the codebase, then makes the change, verifies it, and opens a pull request. For example: > @indent The `/export` endpoint times out on large accounts. Paginate it, and add a test that > covers an account with 10k+ records. Indent runs in a fresh sandbox with your repository cloned, plus a shell and a browser. It has your code but not your build — dependencies aren't installed and services aren't running. Some tasks need your application built and running: the full test suite, a live service, or the UI in a browser. For those, start the session in an [environment](/getting-started/environments) you've configured, where everything is ready from the first message. > **Note** > > Install the GitHub App for repository access and connect your personal GitHub account for pull > requests you ask Indent to open. Configure both from [**GitHub in > Integrations**](https://app.indent.com/integrations/github%3Aworkspace). See [Connecting > GitHub](/connecting/github). ## Iterate in the session and on the pull request The session stays connected to the pull request it opens, so you can keep working on the change: - **Review comments** — a teammate's comment on the pull request routes back to the session. Reply directly in an inline thread and Indent responds without a mention; in a top-level comment, mention `@indent`. - **CI failures** — a failing check comes back to the session, where Indent reads the logs, decides whether the failure relates to the change, and pushes a fix. - **Your follow-ups** — a message in the session refines the approach or redirects the work. If the session has suspended, a new message resumes it. ## What Indent can build - **Bug fixes** — Indent reproduces the issue, traces the root cause, fixes it, and verifies. - **Features** — Indent scaffolds new functionality, wires it into existing code, and runs tests. - **Infrastructure and configuration** — Indent edits CI pipelines, Dockerfiles, and deployment configs. - **Assets and non-code files** — Indent edits SVGs, config files, migration scripts, and anything else in the repository. ## Give Indent more to work with The more Indent knows about your codebase, the better its changes fit: - [AGENTS.md](/learning/agents-md): repository guidance kept with your code. Local desktop sessions load it automatically; in cloud sessions, ask Indent to read it. - [Skills](/learning/skills) — reusable workflows Indent pulls in when a task matches. - [Connected databases](/connecting/databases) — schema and data Indent can query while it works. For more on framing tasks well, see [Getting good results from Indent](/working-with-indent/getting-good-results).