GPT-5.3-Codex now powers Amp's deep mode.

It’s a truly impressive model. After using it, we realized: "The coding agent is dead."

Everything is changing again. With GPT-5.3-Codex, the agent is no longer the bottleneck. Our ability to tell it what to do is.

In our experience, it's a better than GPT-5.2-Codex in every dimension. It still goes deep, but it's learned when to stop.

To use it: open the command palette with Ctrl-O and run the command mode: use deep in the Amp CLI, or select deep mode in the Amp editor extension's prompt field.

Original source Report a problem

Amp frontier update

The current generation of coding agents is dead. The heart is still beating, yes, but the bullet has already left the chamber. This generation isn't the future.
With the newest models, the agent — the prompts and tools you wrap around a model — is no longer the limiting factor. These models can be powerful with nearly any tool you throw at them. A simple tool called bash is often enough. Whether you show LSP diagnostics here or there is dwarfed by what these models can do through sheer brute force. As long as it mostly gets out of the way, nearly any agent can get good results out of them. These new models barely need to be told how to act like coding agents anymore. They're now fully trained for that.
How you organize your codebase for agents, how your organization uses them — those are now the bottlenecks.
The frontier has shifted. And we're going to make massive changes to Amp so it stays on the frontier.
It's tempting not to. Amp is growing faster than ever. We could stay, keep things as they are, pretend that the coding agents of February 2026 are the final form and watch the numbers go up. We could say yes to more VC money and sell $2,000 worth of tokens for $20 a month.
But what would that buy us? A local maximum. And while we're sitting on top of the local maximum, each new model generation would move the frontier further and further into the distance. And the longer we keep things the same, the more we select for users that aren't comfortable at the frontier. But the users we want and need are those who are willing to pack up and travel light with us.
So, Amp has to evolve.

First step:

we're going to kill the Amp editor extensions for VS Code and Cursor. We're unshackling these models from the editor.
By keeping these new models in an editor sidebar, we restrict them. They're now much more than mere assistants. They no longer need the hand-holding and really want to kick off their training wheels. They want to write code and run even when you're not sitting in front of your editor. It's time to see what they can do without supervision.
The Amp editor extensions will self-destruct on March 5 at 8pm Pacific Time. Time to switch to the Amp CLI.
Because we're keeping the CLI, for now. Its heart is still beating and it helps us get to where we need to go. Think of it as a ladder: we use it to climb up to the next level and then we might not need it. It's flexible, light, easy to change, can be run anywhere and anytime. It attracts the kind of users we're building for.
For those of you who read "everything is changing" on our landing page back in April 2025 and nodded, this is nothing new. Our only promise was that when the frontier moved, we would move too.
If you're new to Amp: welcome. Come with us. Today Amp ceases to be a coding agent. It's no longer a point on a map. It's an arrow. Not a stop, but a ride.
And it might self-destruct too.
1,213,534 seconds left

Original source Report a problem

How We Think About Permissions

In our experience, agents work best when they can get feedback about the changes they are making. For example, when they’re able to run tests and see the results of the test run.

Taking tools away, like preventing the agent from reading certain files, makes the agent look for an alternative, like running a Bash command instead to access file contents.

Most people do not worry about file edits anymore, because Git makes the cost of a wrong edit negligible. Restrictions aren’t necessary for tools like this with an easy undo action.

Alternatively, you can set up rules for what the agent is allowed to do with and without asking you. This means Amp will interrupt you more frequently, but in exchange you can examine what Amp is about to do before it triggers a deploy, or accesses the production database.

Amp’s Permission System allows for both modes of operation.

“I don't want the agent to run npm exec.”

You already rely on many sources of feedback, some of them very subtle, to develop software successfully.

It’s the little red squiggles under a typo, the errors produced by the compiler, the failures you get when running your test suite.

While state-of-the-art models are better than most humans at generating working code in one try without feedback, they still need feedback just like you to work effectively in real-world projects.

This feedback allows them to iterate, finally converging on a solution that meets all the constraints imposed by the project, and your task at hand.

Only through running external tools like the type checker and your test suite can the model learn about any mistakes it has made.

With precise instructions like “Use npm test to run the test suite”, you’ll find the model doing just that when it’s time to run the tests.

“AI just dropped my production database!”

While this is a popular story on X, it is usually one told by people new to software development.

You, of course, know that database backups are critical because they reduce the potential damage of database-related accidents to near zero.

Similarly, version control eliminates any damage from undesired file edits.

The same goes for letting the model commit to git: the cost of doing it is low, because commits can be dropped and amended easily.

Errors occur both for models and humans, and building an environment acknowledging this produces better outcomes than trying to prevent all errors in the first place.

“Allow All feels scary and is not granular enough!”

This is true! And so is the opposite: “I’m tired of approving so many tool calls for a simple task!”

We have observed there being two kinds of operators:

• risk-tolerant ones using frontier coding agents all day, often running multiple instances at the same time;
• and cautious users who like to stay in control, carefully reviewing every step the agent takes.

Both groups’ needs are valid, and Amp’s Permissions system supports that.

Before performing any tool call, Amp checks all permission rules in sequence until it finds a matching rule.

The matching rule tells Amp what action to take.

These rules are stored in your settings under the amp.permissions key and can be edited in a more convenient text format.

The examples below use the CLI, and the same functionality is available in VS Code through the “Amp: Edit User Permissions” command.

“I want the agent to take the wheel, running in full-auto mode.”

This sets your permissions to just two rules, asking you when Amp wants to run commands which look like they are mass-deleting files.

amp permissions edit <<'END'
ask Bash --cmd '*rm*rf*' --cmd '*find*exec*' --cmd '*find*delete*'
allow '*'
END

“I do not want Amp to read any of my dotfiles.”

The following adds a rule to the beginning of your rules list, which makes Amp ask every time it tries to read a file whose name starts with . in your home directory.

amp permissions add ask Read --path "$HOME/.*"

You can verify this behavior with the test command:

amp permissions test Read --path "$HOME/.bashrc"

tool: Read
arguments: {"path":"/Users/dhamidi/.bashrc"}
action: ask
matched-rule: 0
source: user

“I want Amp to create Jira issues, but only in a specific project.”

Using Atlassian’s MCP server for accessing Jira, you can tell Amp to modify issues in the EXPERIMENT project without asking, while asking you for the same operations in any other project.

Using amp tools list we can see Jira-related tools exposed by the server:

amp tools list | awk '$1 ~ /[iI]ssue/ { print $1 }'

mcp__atlassian__addCommentToJiraIssue
mcp__atlassian__createJiraIssue
mcp__atlassian__editJiraIssue

... rest omitted ...

Running amp tools show mcp__atlassian__createJiraIssue , we can see that the tool expects a projectKey parameter.

With this information in hand, we can create two rules, the first for making Amp ask before creating issues:

amp permissions add ask mcp__atlassian__createJiraIssue

And a more specific one, allowing Amp to create issues when the project key is EXPERIMENT :

amp permissions add allow mcp__atlassian__createJiraIssue --projectKey "EXPERIMENT"

“I don't want Amp to accidentally push to GitHub.”

The Bash tool accepts the entire shell command pipeline to run in the cmd parameter.

This is a string containing source code, so we need match any command line that looks like a git push command:

amp permissions add ask Bash --cmd '*git*push*'

The * is a wildcard, so this rule will match all of these command lines:

cd ../other-repo && git push
git commit -m 'WIP' && git push
git --work-tree=. push origin

“Amp must not modify my infrastructure.”

In a similar vein, you might want to restrict Amp from modifying infrastructure through terraform or kubectl , while still allowing Amp to inspect the current state of deployed infrastructure.

This rule allows all terraform commands:

amp permissions add allow Bash --cmd "*terraform*"

Then we add a more specific rule rejecting destructive terraform commands:

amp permissions add reject Bash --cmd "*terraform*apply*" --cmd "*terraform*destroy*" --cmd "*terraform*force-unlock*"

“I need even more control.”

Amp allows you to provide a helper program which is responsible for making the decision about each tool call.

Here’s how you tell Amp about the helper, let’s call it amp-permissions-helper :

amp permissions add delegate --to amp-permissions-helper '*'

And then you’ll write a tiny program called amp-permissions-helper and put it on your $PATH .

The program receives the tool parameters on stdin as JSON, and makes a decision with its exit code:

0 allows the tool call,
1 makes Amp ask, and
2 rejects the tool call, forwarding stderr to the model.

This little helper program will reject git push when there are unstaged changes, and allow every other command.

#!/usr/bin/env bash

attempted_command=$(jq -r .cmd)

if ! [[ $attempted_command =~ git.*push ]]; then
  # allow, we only care about git push
  exit 0
fi

if ! git diff --quiet ; then
  printf "Ask the user how to proceed, there are unstaged changes." >&2
  exit 2
fi

“How can I centrally manage permissions?”

Open Policy Agent is a popular piece of software for centrally managing access control rules.

You’d define your policies in one location and make them accessible using the OPA server.

Using a permission helper, you can forward tool arguments to the OPA server and let it make the decision according to a central ruleset:

Let’s say we have this policy running on the server:

# Default result
default action := "ask"

# Reject git push commands in Bash
action := "reject" if {
    input.toolName == "Bash"
    regex.match(".*git.*push.*", input.args.cmd)
}

# Allow other Bash commands
action := "allow" if {
    input.toolName == "Bash"
    not regex.match(".*git.*push.*", input.args.cmd)
}

Then we can query the OPA server like this:

#!/usr/bin/env bash

tool_input=$(jq -r .)
tool_name="$AGENT_TOOL_NAME"
policy_input=$(jq --arg name "$tool_name" --argjson args "$tool_input" -n '{input:{toolName: $name, args: $args}}')

# {"result": $value }
response=$(curl -s -XPOST --data-binary "$policy_input" -H "Content-Type: application/json" $OPA_SERVER/data/amp/action)

case $(jq -r .result <<< "$response") in
allow)
  exit 0
  ;;
ask)
  exit 1
  ;;
reject)
  exit 2
  ;;
*)
  exit 1
  ;;
esac

Original source Report a problem

Code review has traditionally been tied to an interface where a human reads diffs

With the original Amp review agent, we moved away from an external review UI into the editor, where comments could be acted on more immediately. Now, we've fully decoupled the review agent completely from any UI, making it a composable and extensible subroutine that can be invoked from many different places where it is useful:

• You can run amp review in the CLI to run the review agent directly
• You can request a review in any thread in smart mode using natural language like "review the outstanding changes" or "review changes since diverging from main"
• You can kick off multiple reviews in parallel from the editor extension review panel

This composability also means you can more easily close the loop by asking the main agent to automatically fix the issues found or by piping review comments into another command.

Invoking the review agent directly using amp review

Requesting a review from within a thread:

Requesting a review from the editor extension diff panel:

Customizing Review with Checks

You can also define Checks within your codebase. Checks are user-defined invariants or review criteria scoped to specific parts of your codebase. They are defined in .agents/checks/ directories.

Here's an example performance check, which you could save to .agents/checks/perf.md :

---
name: performance
description: Flags common performance anti-patterns
---
Look for these patterns:
- Nested loops over the same collection (O(n²) → O(n) with a Set/Map)
- Repeated `array.includes()` in a loop
- Sorting inside a loop
- String concatenation in a loop (use array + join)
Report the line, why it matters, and how to fix it.

The code_review tool will kick off a separate agent for each check. This provides a stronger guarantee that each check will actually be checked than if the checks were embedded in a general context file like AGENTS.md .

Here are some more examples of useful checks:

• Performance best practices specific to your stack
• Common anti-patterns your team has hit before
• Security best practices or invariants
• Migration reminders for deprecated APIs
• Stylistic conventions that aren't in the linter
• Compliance requirements

Checks are scoped to the directory that contains .agents/ , so a root .agents/checks directory would cover the entire codebase while api/.agents/checks would cover files under api/.

Original source Report a problem

Shareable Walkthroughs are a new interface we're trying—a way to create and share annotated diagrams with your team.
Ask Amp to use the walkthrough skill to explain a feature, function, database schema, or any part of your codebase. It generates an interactive diagram where each node contains detailed context. The Walkthrough diagram lets you start at a high level and drill down into the details you care about.

Examples

• Understand how something in your codebase works

• Ask the walkthrough skill to explain any part of your code with a clickable diagram that links directly to the source.

• Use the walkthrough skill and explain the process of what happens when an email invite is accepted by a user.

• View Walkthrough

• Combine with the librarian to understand libraries and packages

• Pair the walkthrough skill with the librarian to explore how external libraries work—great for understanding new features or comparing versions.

• Use the librarian, look at Svelte version 5 and explain how event handling has been improved. Can you compare this to Svelte version 4? Use the walkthrough skill to explain the differences.

• View Walkthrough

• Generate different diagram types for your use case

• The walkthrough skill can produce various diagram types. Just specify what you need—for example, ask for an ER diagram when exploring database relationships.

• Use the walkthrough skill and explain how the invites entity is stored in the database, what depends on it. Use an ER diagram.

• View Walkthrough

Advanced: Combine with custom tools and data sources

• You can pair the walkthrough skill with additional data sources and tools you've built to visualize answers to complex questions.
• Query the lineage SQLite database to find all dependencies for the [calculated_field_name] field in [CTE_name] job, then use the walkthrough skill to show how it's calculated and trace the impact of changing its logic—upstream sources, downstream consumers, and breaking changes.

Original source Report a problem

Amp has a new agent mode: deep

It uses GPT-5.2-Codex and a selection of tools that are tuned to what this model is good at.
Where smart is eager, collaborative, and happy to edit right away, deep will silently read files and move through the codebase for five, ten, sometimes fifteen minutes before making changes - happy to be left alone.
GPT-5.2-Codex in deep is not an assistant that's constantly checking in with you. It wants to go off and solve problems on its own, not pair program. But that requires a clear definition of the problem up front, which you'll either need to provide in your first prompt, or ask deep to work out with you before you tell it to go and implement it.
Here are some prompts that worked really well in deep mode:

• Nicolay, changing how Skills register MCP tools: "A user has multiple skills, each skill has a mcp.json with the same server name and url, but with different includeTools list. So each skill uses a different subset of tools. Each mcp can only be registered once and last registration wins. But for each mcp within a skill we are only registering its subset of tools. So when the user has multiple skills, it is probably only having one set of tools being registered instead of all. How can we fix this? we could: [...]"
• Thorsten, fixing a theme bug, and providing a screenshot: "Ever since we added @doc/cli-themes.md there's a bug: the selected message has a different color than normal messages. It should match."

The autonomy of deep has limits: it's very good at fixing issues in one go, but it's also very lazy when it comes to running commands or checking its work. It also doesn't pay as much attention to AGENTS.md files as Opus does. That's an area we're actively improving.
We're very excited by how deep complements smart: use smart when you want to interactively work on something together, or get chores done; use deep when you want it to research thoroughly or fix hairy problems on its own. You can now also ask the agent to handoff to deep or smart mode.
To use it: run command mode: use deep in the Amp CLI, or select deep mode in the Amp editor extension's prompt field.

Original source Report a problem

We're removing Amp Tab

We're removing Amp Tab. It is not part of the future that we see.

A year ago, most of our code was written by hand. In June, when we released Amp Tab, Amp was already writing the majority of our code. But now, Amp writes 90% of what we ship.

Amp Tab and other completion engines come from a world in which everyone believed humans will write most of the code and AI is sprinkled on top.

But that world is dying! Look around! Some of our users are saying they haven't opened their editor in days and yet still shipped code. The bottleneck is now how fast you can get the code out, not how fast you can write it, they say.

The era of tab completion is coming to an end. We're entering the post-agentic age, in which it's a given that agents write most of the code.

There's so much to figure out, so much to build, so much to explore! We have to choose what to focus on.

We're focusing on what's coming next, not what brought us here.

Amp Tab will continue to work until the end of January 2026. After that, we can recommend Cursor, Copilot, or Zed if you need inline completions.

Here's Quinn and Thorsten on the end of Amp Tab and how they feel about it (Quinn will miss it):

Original source Report a problem

Fork deprecation

We're ripping out the Fork command.
We added thread forking back in July 2025 (now ancient, primordial history) as a way to conveniently share context for branching experiments or side quests in Amp.
Today we have better ways of sharing context between threads: handoff and thread mentions, which treat threads as first-class stores of context.
Perhaps there is a great potential UX out there for fork, but we want Amp to be simple as well as powerful. We'd rather spend our time perfecting handoff and thread mentions than support fork.

Handoff

Handoff is great for extracting useful context from your thread for the next goal at hand. This means you can start a new thread with only the necessary context.

• Use thread: handoff from the command palette.
• Prompt your task and a new thread will be started with the necessary context already in the prompt.

Thread Mentions

Thread mentions let you pull information from other threads into your current thread. You can reference multiple threads, merging context from many sources.

• Use thread:new and then use the enter shortcut to start a new thread with a reference to the main thread.
• Or, use @@ to search for the thread you want to pull context from.
• Once you run your prompt, Amp will read the threads and extract context pertinent to your task.

Managing Threads

Using new threads as branches leads to many threads, often running in parallel. To manage them:

• use thread: switch to previous or thread: switch to parent to return to the main thread.
• use the thread: map to get a birds eye view and easily navigate back to the main thread (CLI only for now).

Original source Report a problem