Claude Code auto mode: Bagong default sa 14 August 2026

Mga binabago ng auto mode sa 14 August 2026

Awtomatikong nagpapatakbo ang Claude Code auto mode ng mga tool call nang hindi humihinto para magtanong sa iyo. Ipinapadala muna nito ang bawat action sa isang hiwalay na classifier model para sa review. Mula 14 August 2026, ito na ang mode na ginagamit sa pagsisimula ng mga bagong session sa Pro, Max, at Team plans. Maaari kang magpalit ng mode anumang oras. Hindi ino-overwrite ang default na dati mo nang itinakda.

Ganito inilalarawan ng documentation ang pagbabago:

Simula 14 August 2026, magiging default permission mode ang auto mode para sa mga bagong session sa Pro, Max, at Team plans. Maaari kang magpalit ng mode anumang oras. Mananatili ang default na ikaw mismo ang nagtakda maliban kung tatanggapin mo ang one-time switch prompt. Hindi magbabago ang default na mina-manage ng iyong organization.

Mas mahalaga kaysa sa petsa ang dalawang clause na ito. Mananatili ang defaultMode na itinakda mo sa sarili mong settings file. Mananatili rin ang default na dine-deploy ng iyong organization sa pamamagitan ng managed settings. Idinagdag sa announcement post na mananatiling optional ang auto mode para sa Enterprise plans at sa mga account na gumagamit ng API sa unang bahagi ng rollout.

Kung nagpapatakbo ka ng Claude Code sa isang VPS (virtual private server), dapat mong basahin ang tungkol sa pagbabagong ito bago ito ipatupad. Ang permission prompt ay isang checkpoint na nangangailangan ng taong nasa keyboard. Sa remote box, kadalasan ay wala ka roon, kaya ang mode na ginagamit sa pagsisimula ng session ang mode na mananatili nang ilang oras.

Mga permission mode ng Claude Code, mula sa pinakamaraming oversight hanggang sa pinakakaunti

May anim na mode. Ang pangalan sa simula ng bawat linya ang value na ilalagay mo sa settings o ipapasa sa --permission-mode.

• default: Nagtatanong si Claude bago gamitin ang bawat bagong tool. Tumatakbo pa rin nang walang prompt ang pagbasa sa loob ng working directory mo. Tinutukoy ng CLI (command line interface) ang mode na ito bilang Manual at tinatanggap ang manual bilang alias mula sa Claude Code v2.1.200.
• plan: Nagbabasa si Claude ng mga file at nagpapatakbo ng mga command para mag-explore, pero hindi nito ine-edit ang source code mo. Naka-block ang mga edit hanggang aprubahan mo ang plan.
• acceptEdits: Tumatakbo nang walang prompt ang mga file edit, kasama ang filesystem commands na mkdir, touch, rm, rmdir, mv, cp at sed. Nalalapat lang ito sa mga path sa loob ng working directory mo o ng additionalDirectories. Kailangan pa rin ng prompt para sa lahat ng iba pang shell command.
• auto: Tumatakbo ang lahat, habang sinusuri muna ng classifier ang bawat action. Pinipilit pa rin ng mga tahasang ask rule ang paglabas ng prompt.
• dontAsk: Awtomatikong dini-deny ng Claude Code ang anumang action na dapat sana ay naglabas ng prompt. Tatakbo lamang ang mga allow rule mo, ang built-in na read-only Bash commands, at ang mga call na inaprubahan ng PreToolUse hook. Hindi kailanman naghihintay ng input ang session.
• bypassPermissions: Nilalaktawan ang mga prompt at safety check, kasama ang pagsusulat sa mga protected path gaya ng .git at .claude.

Pindutin ang Shift+Tab habang nasa session upang mag-cycle mula default patungo sa acceptEdits at pagkatapos ay sa plan. Ipinapakita ng status bar kung saang mode ka napunta, gaya ng ⏵⏵ auto mode on o gray na ⏸ manual mode on. Hindi kasama ang iba pang mode sa cycle na iyon bilang default. Sumasali rito ang auto kapag natugunan ng account mo ang mga requirement para rito. Sumasali lang ang bypassPermissions kapag sinimulan ang session gamit ang --permission-mode bypassPermissions o --dangerously-skip-permissions. Hindi kailanman lumalabas doon ang dontAsk, kaya itakda ito gamit ang claude --permission-mode dontAsk.

Kailangan din ng Auto mode ng kamakailang model, na karaniwang dahilan kung bakit hindi ito lumalabas. Noong August 2026, nakalista sa documentation ang Claude Opus 4.6 o mas bago, Sonnet 4.6 o mas bago, at Fable 5 sa Anthropic API. Nakasaad din doon na hindi suportado sa anumang provider ang mas lumang mga model gaya ng Sonnet 4.5. Kung iniulat ng Claude Code na hindi available ang Auto mode, hindi natutugunan ang isa sa mga requirement na iyon. Hindi ito pansamantalang outage, kaya hindi ito maaayos sa paghihintay.

Dalawang control ang nalalapat sa bawat mode, kabilang ang bypassPermissions: mga deny rule at tahasang ask rule. Ito ang mga control na hawak mo anuman ang mode na pinagsimulan ng session.

Ano ang bina-block ng auto mode classifier

Ang classifier ay isang hiwalay na model na nagbabasa sa nakabinbing action at nagpapasya kung naaayon ito sa ipinagawa mo. Inilalarawan ng documentation ang tungkulin nito sa isang pangungusap:

Sinusuri ng hiwalay na classifier model ang mga action bago isagawa ang mga ito. Bina-block nito ang anumang lumalampas sa ipinagawa mo, nagta-target ng hindi nakikilalang infrastructure, o mukhang dulot ng mapaminsalang content na nabasa ni Claude.

Bina-block bilang default ang mga sumusunod na kategoryang pinakamadalas makaharap ng server operator:

• Pagda-download at pag-execute ng code, gaya ng curl | bash
• Production deploy at migration
• Force push
• Pagbabago sa shared infrastructure
• Pagbubukas ng tunnel o reverse shell na ginagawang reachable mula sa public internet ang isang local service
• Pagpi-print ng live credential o token sa transcript o sa isang file

Pinapahintulutan bilang default ang mga sumusunod:

• Mga local file operation sa working directory mo
• Pag-install ng dependencies na idineklara sa lock files o manifests mo
• Read-only HTTP request
• Pag-push sa anumang branch ng repository na ginagamit mo

Huwag umasa sa buod na gaya ng nasa itaas. Patakbuhin ang claude auto-mode defaults upang i-print ang buong rule list bilang JSON, at basahin ang set na kasama ng version na naka-install sa iyo.

Mahalagang malaman ang 2 documented limit bago ka umasa rito. Una, nakikita ng classifier ang mga message mo, tool call, at CLAUDE.md content mo, ngunit inaalis ang tool result. Dahil dito, hindi direktang maaabot ng text sa file o web page na binasa ni Claude ang classifier. Ikalawa, kapag bina-block ng classifier ang isang action nang 3 magkakasunod na beses o 20 beses sa isang session, ipo-pause ang auto mode at babalik ang Claude Code sa paghingi ng kumpirmasyon sa iyo. Hindi configurable ang mga threshold na ito. Sa non-interactive mode na may -p flag, walang taong mapagtatanungan, kaya sa halip ay ina-abort ng paulit-ulit na block ang session.

Ang ikalawang behavior ang nagiging problema sa isang remote box. Kapag lumampas sa limit ang isang unattended run, hihinto ito at maghihintay ng taong hindi nakatingin sa terminal. Bahagi rin ng solusyon ang paglilimita sa layunin ng agent, at ang skill na nagtutulak sa agent na gawin ang pinakamaliit na pagbabagong gumagana ay pumipigil sa session na malihis patungo sa malawakang mga action na bina-block ng classifier.

Kung saan makikita ang mga mode sa settings.json

Ang lahat ng nasa itaas ay isang object sa isang settings file.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Sinusuri ang mga rule ayon sa pagkakasunod-sunod: deny, pagkatapos ask, at saka allow. Ang unang tumugmang rule sa pagkakasunod-sunod na iyon ang magpapasya sa resulta. Hindi mananaig ang mas tiyak na rule laban sa mas malawak na rule na nauna. Bina-block ng deny rule para sa Bash(aws *) ang aws s3 ls kahit pinayagan mo rin ang eksaktong command na iyon. Kaya hindi maaaring magkaroon ng exception ang deny rule.

Ang ask ang uri ng rule na kapaki-pakinabang sa auto mode. Inaalis ng auto mode ang karaniwang prompt. Naglalagay naman ang ask rule ng prompt para sa partikular na command na gusto mong mangailangan ng approval ng isang tao. Dito dapat ilagay ang deploy command mo. Ganoon din ang Bash(git push *) kung gusto mo ng checkpoint bago lumabas ang code sa server. Ang paglalagay ng credential files sa deny ang kabilang bahagi nito. Kaugnay din ito ng pag-iwas na mapasakamay ng agent ang credentials.

Ang mismong settings file, mula sa pinakamababang precedence:

• ~/.claude/settings.json: settings ng user mo, na inilalapat sa bawat project.
• .claude/settings.json: settings ng project, na naka-commit sa repository.
• .claude/settings.local.json: sarili mong settings para sa isang repository, na naka-git-ignore.
• Managed settings, na dine-deploy ng administrator. Sa Linux, ang file na iyon ay /etc/claude-code/managed-settings.json. Walang makapag-o-override sa managed permission rule, kabilang ang command line flag.

May isang trap dito na may dokumentadong dahilan. Binabalewala ang defaultMode: "auto" kapag nagmumula ito sa .claude/settings.json o .claude/settings.local.json, simula sa Claude Code v2.1.142, upang hindi makapag-enable ang isang repository ng auto mode para sa sarili nito sa pamamagitan ng pag-ship ng settings file. Kapag itinakda mo ito roon, magsisimula ang session sa default mode nang walang error na ipinapakita kahit saan. Ilipat ang line sa ~/.claude/settings.json. Patakbuhin ang /permissions upang ilista ang lahat ng aktibong rule at ang file kung saan nagmula ang bawat isa.

Ang dalawang switch para i-off ang isang mode

May dalawang kill switch ang mga administrator, at parehong tumatanggap ng string na "disable" sa halip na boolean.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

Tumpak ang dokumentasyon kung saan ilalagay ang mga ito:

Para pigilan ang paggamit ng bypassPermissions o auto mode, itakda ang permissions.disableBypassPermissionsMode o permissions.disableAutoMode sa "disable" sa anumang settings file. Pinakamahusay gamitin ang mga ito sa managed settings na hindi maaaring ma-override.

Inaalis ng disableAutoMode ang auto sa Shift+Tab cycle at nire-reject ang --permission-mode auto sa startup. Ganoon din ang ginagawa ng disableBypassPermissionsMode para sa bypass mode, at gumagana ito sa anumang scope. Kaya maaari mo itong itakda sa sarili mong ~/.claude/settings.json upang hindi mo ma-access ang mode na mas mabuting hindi mo pagpilitang gamitin alas-2 ng umaga sa isang live server. Sa isang server na ginagamit ng ibang tao, ilagay na lang ang dalawa sa /etc/claude-code/managed-settings.json, dahil pagmamay-ari ng user ang user settings file, samantalang hindi pagmamay-ari ng user ang managed settings file.

Bakit kailangan ng isolation boundary ng auto mode sa isang VPS

Sinusuri ng classifier ang bawat action nang paisa-isa. Hindi nito kinokontrol ang ginagawa ng isang aprubadong action pagkatapos nitong tumakbo. Malinaw ang hangganang inilalarawan sa documentation:

Ang classifier ay per-action control, hindi isolation boundary. Kaya nagbibigay pa rin ng defense in depth ang isolation boundary para sa unattended runs, at hindi ito kinakailangan sa paraang kinakailangan ito para sa --dangerously-skip-permissions.

Kaya para sa isang remote box, ang tamang kombinasyon ay auto mode at environment na handa mong mawala, hindi bypassPermissions at pag-asa. Nakadokumento ang bypass mode para lamang sa mga isolated environment: containers, virtual machines, o dev containers na walang internet access, kung saan hindi kayang sirain ni Claude Code ang host system mo. Ang VPS na nagpapatakbo ng database at reverse proxy mo ay wala sa alinman sa mga iyon.

Tatlong bagay ang pinakamahalaga sa isang server. Patakbuhin ang Claude Code bilang normal user, at huwag kailanman bilang root. Bigyan ang user na iyon ng working directory at wala nang ibang may mahalagang mabasang data. I-rebuild ang box sa halip na ayusin ito. Ito ang dahilan kung bakit praktikal ang disposable VM na itinatapon pagkatapos ng bawat job. Saklaw ng buong safety pass para sa pagpapatakbo ng Claude Code sa isang VPS ang mga detalye ng hardening para sa mga ito, mula sa paggawa ng user hanggang sa firewall rules, kaya hindi na ito inuulit dito.

Ipinapatupad mismo ni Claude Code ang root rule. Sa Linux at macOS, tumatanggi itong magsimula sa bypass mode kapag nasa ilalim ng sudo o kapag root ang user:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Nilalaktawan ang check na ito sa loob ng isang kinikilalang sandbox. Kaya ang dokumentadong sagot para sa autonomous container work ay isang dev container na nagpapatakbo ng Claude Code bilang non-root user. Kung pinapatakbo mo ang agent mula sa phone o laptop sa pamamagitan ng SSH, pareho ang prinsipyong nalalapat sa long-running Claude Code session na nananatiling bukas sa tmux: walang nagbabantay sa prompt habang tumatakbo ang session.

I-set up ang Bash sandbox sa isang Ubuntu VPS

Nililimitahan ng built-in sandbox ang filesystem at network access ng bawat Bash command na pinapatakbo ni Claude, at ipinapatupad din ng operating system ang mga limitasyong ito sa mga child process. Sa Linux, kailangan nito ng dalawang package.

sudo apt-get install bubblewrap socat

I-start ang Claude Code at patakbuhin ang /sandbox. Magbubukas ang panel na may Mode tab at Overrides tab, pati Dependencies tab na naglilista ng anumang nawawalang dependency. Tumatakbo ang dependency check sa startup, kaya i-restart ang Claude Code pagkatapos i-install ang mga package. Kung hindi, patuloy na iuulat ng panel na wala ang mga ito.

Sa Ubuntu 24.04 at mas bago, pinipigilan ng default na AppArmor policy ang bubblewrap na gumawa ng mga user namespace na kailangan nito, kaya hindi nagsisimula ang sandbox. Suriin kung naaangkop ito sa iyong server:

sysctl kernel.apparmor_restrict_unprivileged_userns

Ang 0, o isang error na nagsasabing wala ang key, ay nangangahulugang walang kailangang gawin. Ang 1 ay nangangahulugang kailangan ng bwrap ng sarili nitong profile:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

Ang profile ay inilalapat sa mismong bwrap, hindi sa mga command na pinapatakbo nito sa loob ng sandbox. Pagkatapos, higpitan ang boundary sa settings:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Dapat ilagay ang block na iyon sa .claude/settings.json ng project, dahil sa project settings lamang nire-resolve ang . bilang project root. Ilagay ang parehong mga linya sa ~/.claude/settings.json, at ang . ay sa ~/.claude naman magre-resolve. Dahil dito, bina-block ng denyRead rule ang mga project file, at hindi mababasa ng bawat command ang code na dapat nitong i-edit.

Alamin kung ano ang hindi nito saklaw. Nililimitahan ng sandbox ang Bash at ang mga child process nito. Tumatakbo ang built-in file tools sa loob ng Claude Code process, habang ang MCP (model context protocol) servers at hooks ay magkakahiwalay na process na walang mga limitasyon sa host. Para mailagay silang lahat sa iisang boundary, patakbuhin ang buong Claude Code process sa loob ng container, virtual machine, o @anthropic-ai/sandbox-runtime package, na beta research preview pa noong isinulat ito.

Aling mode ang angkop sa bawat setup?

Isang repo sa sarili mong laptop

Gamitin ang auto, na may mga panuntunan ng ask para sa mga action na gusto mong payagang magpatuloy. Nasa keyboard ka, aktuwal kang maaabot ng classifier fallback, at limitado sa isang machine na kontrolado mo ang posibleng pinsala. Ito ang sitwasyong pinagbatayan ng default noong 14 August.

Shared VPS

Gamitin ang auto para sa bawat user, at i-set ito sa sariling ~/.claude/settings.json ng bawat user, sa isang box kung saan hindi root ang account na nagpapatakbo ng Claude Code at hindi nito mababasa ang work ng ibang user. I-deploy ang disableBypassPermissionsMode bilang "disable" sa /etc/claude-code/managed-settings.json, kasama ang mga deny rule na nagpoprotekta sa shared path. Ang shared box ang pinakamalinaw na sitwasyong mali ang bypassPermissions, dahil wala rito ang isolation boundary na ipinapalagay ng mode na iyon: nasa loob nito ang ibang tenant.

CI at unattended session

Gamitin ang dontAsk kasama ang malinaw na listahan ng allow ng mga command na kailangan ng job. Ang auto-deny ang tamang failure mode kapag walang taong makakakita ng prompt. Non-interactive din ang pagtakbo ng Auto mode, ngunit ina-abort ng paulit-ulit na classifier block ang -p session, kaya nabibigo ang job sa kalagitnaan habang hindi pa tapos ang work. Panatilihin ang bypassPermissions para sa isang container o virtual machine na nire-rebuild mo mula sa image, at huwag itong gamitin sa host na nagpapatakbo rin ng anumang mahalagang serbisyo.

FAQ

Kailan nagiging default ang auto mode sa Claude Code?

Mula 14 August 2026, magiging default ito para sa mga bagong session sa Pro, Max, at Team plans. Ayon sa documentation, maaari kang magpalit ng mode anumang oras. Mananatili ang sarili mong default maliban kung tanggapin mo ang one-time switch prompt. Hindi mababago ang default na pinamamahalaan ng iyong organization. Nananatiling optional ang auto mode para sa Enterprise plans at sa mga account na gumagamit ng API sa unang bahagi ng rollout. Tingnan ang status bar upang makumpirma ang aktuwal na mode ng session. Nakalagay doon ang ⏵⏵ auto mode on kapag auto mode.

Dapat ko bang gamitin ang auto mode o bypassPermissions sa isang VPS?

Gamitin ang auto mode kasama ng isolation boundary. Sinusuri ng classifier ang bawat action bago ito patakbuhin. Ngunit malinaw sa documentation na per-action control lamang ito at hindi isolation boundary. Kaya kailangan pa rin ng container, virtual machine, o server na handa mong i-rebuild para sa unattended run. Nilalampasan ng bypassPermissions ang lahat ng check. Nakadokumento ito para lamang sa isolated environments. Ayaw magsimula ng Claude Code sa mode na ito kapag root ang user sa Linux, at ipinapakita nito ang --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

Paano ko mapipigilan ang lahat ng user sa server na gumamit ng auto mode o bypass mode?

Itakda ang permissions.disableAutoMode at permissions.disableBypassPermissionsMode sa string na "disable" sa /etc/claude-code/managed-settings.json. Nauuna ang managed settings sa lahat ng ibang scope. Dahil dito, hindi ito mao-override ng anumang user settings file o command line flag. Tinatanggal ng disableAutoMode ang auto sa Shift+Tab cycle at tinatanggihan ang --permission-mode auto sa startup. Gumagana rin ang disableBypassPermissionsMode sa anumang scope, kaya maaari itong itakda ng isang user sa sarili niyang ~/.claude/settings.json.

Bakit hindi pinapansin ang setting kong defaultMode: "auto"?

Dahil nasa maling file ito. Simula sa Claude Code v2.1.142, binabalewala ang defaultMode: "auto" kapag nagmula ito sa .claude/settings.json o .claude/settings.local.json. Pinipigilan nito ang isang repository na awtomatikong mag-enable ng auto mode sa pamamagitan ng paglalagay ng settings file. Nagsisimula ang session sa default mode at walang ipinapakitang error. Ilipat ang setting sa ~/.claude/settings.json, pagkatapos ay patakbuhin ang /permissions upang makumpirma kung saang file nagmula ang bawat aktibong rule. Kung hindi pa rin available ang auto mode, tingnan ang model requirement. Hindi supported sa anumang provider ang mas lumang mga model gaya ng Sonnet 4.5.