If the Developer Console has vanished from your Salesforce org, nothing is broken. The Winter '27 release notes say the Developer Console option is not visible in Setup by default, and they present the new Web Console as its replacement. An administrator can switch the Developer Console back on in a few clicks.
Whether you should is a different question. Salesforce presents the Web Console as the replacement. We could not find a retirement date for the Developer Console in the release note or the developer guide, so treat the switch as a bridge while you decide what to use next. This post covers what changed, how to get the Developer Console back, how the options compare, and where the orgadmin.ai Development Studio fits, including what it cannot do.
What changed in Winter '27
Everything below comes from Salesforce's own Winter '27 release note and its Web Console developer guide.
- The Developer Console is hidden by default. Salesforce describes the Web Console as a lightweight, browser-based IDE built on VS Code for Web.
- The Developer Console is still there. If Web Console is set to Inactive in your org, the Developer Console is active by default. If both are Active, both appear.
- Only administrators can change it. The guide says individual users cannot enable or disable the Web Console, or change the default IDE, for themselves.
- Salesforce positions the Web Console as the replacement for the Developer Console and for Workbench, which the guide calls officially unsupported. The release note describes it as free in all supported editions and environments.
One caution. Parts of Salesforce's Web Console guide still carry beta labels and say the console stays off until an admin turns it on, while the release note describes the new default. If your org behaves differently from this post, trust the setting in Setup over either document.
How to turn the Developer Console back on
You need to be an administrator.
- Open Setup and type Development in the Quick Find box.
- Select Web Console.
- Switch the Enable Developer Console setting to Active.
Leave the Web Console active too if you want both options while your team makes the move. If you set the Web Console to Inactive instead, Salesforce says the Developer Console activates by default to restore the standard setup buttons.
If you are on Government Cloud
Salesforce has a known issue (W-24041529) where, after Government Cloud preview sandboxes upgrade to Winter '27, neither console appears. The Web Console feature is switched off there, so the setting above does not exist. At the time of writing (3 October 2026) its status is "Solution Scheduled". Salesforce lists two workarounds: switch to Salesforce Classic and open the Developer Console from the user menu, or append /_ui/common/apex/debug/ApexCSIPage to your org's My Domain URL. If neither works, contact Salesforce Support, which says a per-org workaround may be available.
Developer Console vs Web Console: what Salesforce says differs
Salesforce publishes its own comparison. In short:
| Developer Console | Web Console | |
|---|---|---|
| Metadata types | Apex, Aura and Visualforce | All metadata types |
| Lightning Web Components | Not supported | Supported |
| Debug logs | Richer log views, and you can open the source from a log | Logs shown as raw text unless you add tools |
| Project context | None | Kept, with in-context editing |
| Interface | Its own layout | Similar to VS Code |
Two rows deserve a test before you commit. Logs: if you spend a lot of time in the Developer Console's log views, check the Web Console against a real log first, because Salesforce's own comparison credits the Developer Console with the richer views. Production: the Web Console keeps Apex read-only in production orgs, so you can inspect code there but not change it. In non-production orgs it is meant for quick fixes, testing and validation.
Also worth knowing: the Web Console's extensions come prepackaged, so you cannot install others from the Visual Studio Marketplace, and Salesforce says Professional Edition orgs get restricted access to code and features.
Your options now
The Web Console. Free, built into Salesforce, and good for inspecting a query, reading a log or making a small fix in a sandbox. Salesforce is clear that it is a lightweight utility rather than a full development environment. It has no version control, because edits go straight to the org, and no AI assistance.
The Agentforce Vibes IDE. Salesforce describes it as a full cloud-based VS Code with the Salesforce CLI, GitHub integration, scratch org testing and AI assistance from Agentforce. Its comparison page lists Professional, Unlimited, Enterprise and Developer editions, and the release note refers to it as a paid tool.
VS Code and the Salesforce CLI on your own machine. The source-driven route, with git, scratch orgs and the most control. It is also the most setup, and the right answer for a team with a real pipeline.
A browser studio outside Salesforce, such as ours. Here is how the three browser options line up:
| Web Console | Agentforce Vibes IDE | orgadmin.ai Development Studio | |
|---|---|---|---|
| What it is | Lightweight editor inside your org | Full VS Code in the browser | Browser editor and AI pair programmer connected to your orgs |
| Aimed at | Quick fixes and investigation | Building complete, multi-file solutions | AI-assisted changes you can review, validate and promote between orgs |
| AI | None | Agentforce-assisted | Your choice of AI provider, with your org's schema and code as context |
| Version control | None | GitHub and source control | Project versions with diffs and restore, but no git |
| Availability | All orgs, per Salesforce | Professional, Unlimited, Enterprise and Developer editions | Any org you can connect, as part of an orgadmin.ai plan |
Where the orgadmin.ai Development Studio fits
The Development Studio is an editor for Apex, Lightning Web Components, flows (which you can read as a diagram as well as XML), permission sets, objects, fields, validation rules and layouts. Alongside it sits an AI pair programmer that can read your org's schema, existing classes, automation and live data before it writes anything, and that works with the AI provider you choose.
The loop is the point:
- Describe the change. The AI looks at your real objects and existing code first, and follows built-in playbooks for Apex, Lightning Web Components, flows and permission sets.
- Review it in the editor. Generated code lands in the editor, not in your org.
- Deploy or validate. In a sandbox you pick a test level. Against production the default is a check-only validation, and a real deployment needs an extra confirmation.
- Let it read the failures. Compile errors and Apex test failures come back from Salesforce with line numbers and assertion messages, and the AI works from those instead of guessing. The errors are Salesforce's, not a local check.
For a quick fix there is also a scratch editor: open an Apex class or Lightning component straight from a sandbox, edit it and save it back, and Salesforce compiles it on save. That path is sandbox-only and limited to workspace owners and admins. For anything you want to keep, use a project. Projects autosave every change as a draft, let you save versions with a message, a line-by-line diff and a restore button, and deploy as one package.
What the Studio does not do
If the Developer Console was your main tool for debugging, you should know where the gaps are before you move:
| If you used the Developer Console to… | In orgadmin.ai |
|---|---|
| Open a class, change it and save | The scratch editor, in a sandbox only. Projects add autosave and versions. |
| Run Apex tests | Tests run as part of a validation or deployment, at the level you choose, and failures come back with assertion messages. There is no standalone test runner. |
| Run a SOQL query | The SOQL console: SELECT-only, live results capped at 5,000 rows, an AI query builder and saved queries shared with your team. It has no query-plan tool. |
| Read a debug log | Debug Logs: a log viewer, plus AI analysis across up to five related logs for exceptions, slow SOQL and DML, and limit use. It reads logs; trace flags are still set in Setup. |
| Execute anonymous Apex | Not available. |
| Use checkpoints or inspect the heap | Not available. |
There is also no git, no Salesforce CLI and no scratch org support. The Studio needs a desktop-sized window, and it is a different tool from a source-driven pipeline. If you work that way, the Vibes IDE or VS Code is the better fit.
How to choose
- A small fix in a sandbox, no AI needed: the Web Console.
- Multi-file feature work with git and scratch orgs: the Vibes IDE, or VS Code with the CLI.
- AI help that sees your real org and reads real compile errors, with review and promotion between orgs and nothing to install: the Development Studio.
- Execute anonymous Apex or checkpoint debugging: keep the Developer Console switched on for now.
What to do this week
- Check the setting. Look at Enable Developer Console in Setup, in a sandbox that has upgraded and again in production when your upgrade lands.
- Decide whether to keep both active while the team moves, and tell people where each lives.
- Test your three most common Developer Console tasks in the Web Console, starting with logs, in a sandbox.
- Try any new tool on a sandbox first. The Studio's first 15 minutes guide shows how to connect an org. Start a free orgadmin.ai trial and connect a sandbox rather than production.
Sources and further reading
- Web Console (Salesforce Winter '27 Release Notes)
- Enable Web Console and the Web Console FAQ (Salesforce Developers)
- Developer Console vs Web Console and Web Console vs Agentforce Vibes IDE (Salesforce Developers)
- Developer Console/Web Console Missing in Winter '27 GovCloud Preview Sandboxes (Salesforce Known Issues, W-24041529)